On Tue, Jan 11, 2011 at 3:02 PM, C. M. Sperberg-McQueen
<[log in to unmask]> wrote:
> On Jan 11, 2011, at 11:34 AM, Bruce D'Arcus wrote:
>> Really awesome set of constructive comments. I just want to respond to
>> one, particularly relevant to my use case.
>> On Tue, Jan 11, 2011 at 1:13 PM, C. M. Sperberg-McQueen
>> <[log in to unmask]> wrote:
>> ...
>>> 5 Why an atomic datatype?
>>> Implicitly, the document seems to take for granted that information in
>>> all of these forms should be representable in what XSD refers to as a
>>> simple type.  But why?
>> Because the expected domain for this spec is, at least in my strong
>> view, not limited to XML documents. For my use case (bibliographic
>> reference and citation formatting),we have a need to be able to
>> represent these sorts of data in RDF (including it's various
>> serialization formats), as well as JSON.
> That suggests that the scope and goals section of the document
> may need work.


> But both RDF and JSON have facilities for structured information; less
> convenient, perhaps, for some things than XML, but still present.
> Surely you don't want to suggest that either is incapable of handling
> this information in a structured way instead of as atoms?

No, but:

a) it would then be completely orthogonal to the W3C/ISO formats in
wide deployment, rather than an extension of it.

b) creating atomic datatypes is relatively easy technically: there's
an infrastructure for using those in standard XML (XSD, RNG, etc.) and
RDF technologies, and you can use the exact same values across those
contexts.  OTOH, creating complete models for different formats is a
headache (do we really want to create an RDF vocabulary, and XML
schemas in XSD and RNG, and something analogous in JSON?).

And it also raises a rather obvious question, which is why should this
effort be any different than the W3C date-time format? E.g. why is it
OK for the latter to be atoms, but not the former?