Re: ACTION on xsi:type recommendation for variable binding results

On Mon, 2005-03-14 at 16:06 -0800, Howard Katz wrote:
> Dave,
> 
> Apologies for jumping into this discussion so late. I didn't see Damian's
> Feb 18 email [1] to the comments list on his suggested use of xsi:type until
> a few days ago and so totally missed the import of your question to me
> during the subsequent telecon. Assuming you won't mind another perspective
> at this late date, I attach the following for what it's worth.
> 
> As background information, xsi:type is a mechanism defined in XML Schema
> Part 1 that's available for adding ad hoc type information to an XML element
> without requiring the presence of an actual schema [2] (altho one can be
> present if desired). In this mechanism, the datatype that's being specified
> is represented by a QName that's the value of the xsi:type attribute. As an
> example:
> 
>     xsi:type="xsd:int"
> 
> XML Schema Part I discusses the question of how to resolve an attribute
> value that has QName content. [3] It says, in essence, that the prefix needs
> to be matched against the prefixes declared for the in-scope namespaces in
> effect for the element, with the 'localPart' part of the name (the part
> after the ':') indicating the name of the type that's being specified. (All
> of which is to say, just remove the quotes and resolve it the same way you
> would a regular QName.)
> 
> To my understanding (I'm don't claim expertise in this area), the original
> impetus for this feature was to provide a form of polymorphism for complex
> element types (indicating an abstract element's actual subtype at runtime),
> but it seems to have been taken up for much wider use to provide an ad hoc,
> "schema-less" datatyping capability, particularly in conjunction with XML
> Schema simple datatypes.

Yes, schemaless is the thing here, to match the rdf datatype attribute
(URI) which is all the sparql/rdf model knows about, an xsi:type for the
xml schema-understanding world.

> SOAP is one W3C client that uses this mechanism extensively, in order to
> indicate the types of marshalled components. [4] It's quite easy to find
> examples on the web. See "Professional Web Services: Simple Data Types [5]
> for one, or do a google on "soap xsi:type".
> 
> To recap Damian's email, he suggests we use the xsi:type mechanism to
> augment the datatype information we already provide in our variable binding
> results xml format, making it available in a more universal format to
> outside processors who don't speak RDF. He provides an XSLT example showing
> how proper sort ordering can result when a Schema-aware XSLT processor is
> able to utilize xsi:type information (as opposed to the "naive" sort
> ordering that occurs without it).
> 
> There's a similar use case to be made for XQuery. The following code would
> correctly sort Damian's example (assuming it were augmented with the
> appropriate xmnls declarations and xsi:type -- see below), again assuming an
> XML Schema-savvy tool:
> 
> for $result in //result
> order by $result/number
> return
>     $result/value
> 
> Here's Damian's original, unaugmented example, in which sorting maintains
> the original ordering of the elements:
> 
> <results>
>    <result>
>      <number datatype="http://www.w3.org/2001/XMLSchema#int">02</number>
>      <value>second</value>
>    </result>
>    <result>
>      <number datatype="http://www.w3.org/2001/XMLSchema#int">1</number>
>      <value>first</value>
>    </result>
> </results>
> 
> Here's the same example augmented with xsi:type mappings and the relevant
> namespace declarations required to support their proper resolution, and
> which sorts "properly", second <value> element first.
> 
> <results
> 	xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
> 	xmlns:xsd="http://www.w3.org/1999/XMLSchema">
>    <result>
>      <number xsi:type="xsd:int"
> datatype="http://www.w3.org/2001/XMLSchema#int">02</number>
>      <value>second</value>
>    </result>
>    <result>
>      <number xsi:type="xsd:int"
> datatype="http://www.w3.org/2001/XMLSchema#int">1</number>
>      <value>first</value>
>    </result>
> </results>
> 
> I think this would be useful to make RDF datatypes accessible to outside
> manipulation. 

Strictly, it makes XML Schema datatypes accessible.  The RDF datatypes
are the URI values of the datatype attribute and cannot always be
written in xsi:type value forms (the reverse is also true).

> ...
> I would recommend we adopt this mechanism, mapping from our
> own number/@datatype attribute to an xsi:type representation whenever an XML
> Schema simple datatype is present in the variable binding results output,
> and emitting the two xmlns declarations on the outer <results> element
> wrapper if any xsi:type attributes have been so mapped.

That makes the header dependent on the body content, potentially the
very last result in a long list could have an XML schema simple datatype
value.  I'd prefer to say that *if* any xsi:type is emitted, then the
two xmlns declarations must be on the outer results allowing the users
to either
  1. always emit it (easy)
  2. or to do it only if they have an XSD simple datatype in a result
  (requires some storage for the full results or some other knowledge). 

I'd expect most people would chose #1.


You also suggest just applying this to the XML Schema simple datatype, I
assume exclusively.  Would other xsi:type values be allowed to be
emitted if the application knew the RDF datatype URI <> XML qname
mapping?  Or forbid this?

One other thought is that the additional in-scope XML namespaces would
"infect" any XML content given.  I'm not sure that's a big problem,
compared to that with RDF/XML's parseType="Literal" where C14N appears.

Dave


> Howard
> 
> [1]
> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2005Feb/0005.ht
> ml
> [2] http://www.w3.org/TR/xmlschema-1/#xsi_type
> [3] http://www.w3.org/TR/xmlschema-1/#d0e16860
> [4] http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#enctypename
> [5]
> http://www.webreference.com/authoring/languages/xml/webservices/chap3/2/2.ht
> ml
> 
> 
> 
>

Received on Wednesday, 23 March 2005 16:07:46 UTC