[Bug 6864] MIME type for built-in datatypes

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6864





--- Comment #4 from C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com>  2009-06-03 02:43:44 ---
[Speaking for myself]

I've just spent some time reviewing this issue and the original poster's clear
and helpful description of his usage of text/plain at

  http://soundadvice.id.au/blog/2009/05/05/#textplain

The end result is, I think, a combination of skepticism about the technical
merits of the proposal and uncertainty about who would be the appropriate body
to undertake the task if the task is to be undertaken.

The XML Schema WG is chartered
(http://www.w3.org/XML/2009/02/schema-charter.html) to finish XSD 1.1 and to
maintain XSD 1.0 and 1.1.  I think we do have an explicit goal of making XSD
Datatypes usable not only in Structures but in other contexts (though I'm not
going to cite a source for that belief unless someone argues otherwise), but I
don't believe creating other specs to use XSD Datataypes is part of the WG's
program of work.  That is, I think the proposal here is strictly speaking out
of scope for the WG.  I am not sure what person or body has particular
responsibility for the health of  the text/* branch of the MIME type hierarchy,
but I rather think that they, not the XML Schema WG, are the responsible party
here.

I admit I might feel differently about the scope issue if I were more enamored
of the proposal.  In that case, I might argue that defining a MIME type with
the proposed semantics would fall under the heading of encouraging adoption of
the XSD spec.  So I should probably outline my reasons for skepticism.

As comment 3 clarifies, what is proposed here is a MIME type with the meaning
"the body of this message is a literal in some built-in XSD datatype or other".
 This strikes me as unhelpfully vague and underspecified, whether the intended
semantics are that the literal belongs to (a) an unspecified XSD datatype,
whether built-in or user-defined, or (b) an unspecified built-in XSD datatype,
or (c) one of the XSD primitive (or special?) datatypes.  And as the blog post
pointed to above mentions, the limitation to XSD datatypes can be sub-optimal
for some expected deployment scenarios, in which other non-XSD datatypes may
also appear (e.g. geolocation information, or measurements for which the unit
of measure is also to be specified). 

The alternative of a suite of MIME types for (let us say) the built-in
primitive datatypes would provide more reliable information about the value
actually being transmitted, but would I gather be more specific and
constraining than the original poster wants.  (I also don't relish the task of
getting approval for a suite of twenty new MIME types, but that may be just a
personal preference to avoid doing any hard lifting.)

It's clear from the blog post cited above that part of the appeal of using
text/plain is that text/plain offers extremely low barriers to entry and usage:
 it's really easy to emit the data, and the data are really easy to use, as
long as you know a priori whether it's going to be an integer (as decimal or as
float or as double) or a gYear or a string or a relative URI reference.  Even a
very simple XML encoding of the information as 

  <datum xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xmlns:xsd="http://www.w3.org/2001/XMLSchema"
               xsi:type="xsd:anySimpleType">1223</datum>

is significantly more complicated for the receiver to parse without an XML
parser.  (Not really very hard, especially if you know the element is going to
be called 'datum' and that the only attributes to expect are the namespace
declarations and the type information, but still intimidating to someone who
thinks text/plain might well work just fine.)  It seems clear that my earlier
suggestion that Web Services might be brought to bear was calculated to horrify
anyone who finds the MIME-type proposal attractive; sorry about that.

But on reflection, I think the answer is:  the relative complexity of XML is
there for a reason, and the XML example just given includes a lot more
information than a message consisting only of 

  1223 

and it adjusts much more readily to change.  Someone wants to transmit a
geolocation encoded using a type defined with DTLL?  Declare appropriate
namespaces, provide appropriate pointers to something to tell you what the
thing is.  If an application really doesn't need the ability to identify a
specific datatype, because all it really needs is the literal, then the
application seems necessarily to have some other channel of information to
provide the necessary background information to enable "1223" to suffice as a
message.  But in that case, I am not quite sure what a MIME type of the kind
suggested here would provide by way of benefit:  it doesn't tell me anything
about where the value came from, or even what kind of thing it is, with any
precision (unless the literal is one of the rare literals which would be legal
as a string but does not appear in any other lexical space).  If I have enough
background information to know whether "1223" denotes a gYear, a relative URI,
an integer, a string, or a time of day written using some non-ISO-8601
convention, or if my application really doesn't need to know any of that, then
I'm not sure why I or my application need to know that the "1223" in the
message is a literal in any of the XSD lexical spaces.  If they need to know
that, then my strong gut feeling is that they probably need to know a lot more.

The upshot, I reget to say, is that I am not sold on this as an enhancement to
XSD 1.1 or as an activity for the XML Schema WG.  Others may of course have
different views.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 3 June 2009 02:44:37 UTC