W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2005

ACTION on xsi:type recommendation for variable binding results

From: Howard Katz <howardk@fatdog.com>
Date: Mon, 14 Mar 2005 16:06:55 -0800
To: "Dave Beckett" <dave.beckett@bristol.ac.uk>
Cc: "DAWG Mailing List" <public-rdf-dawg@w3.org>


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


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.

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

Here's Damian's original, unaugmented example, in which sorting maintains
the original ordering of the elements:

     <number datatype="http://www.w3.org/2001/XMLSchema#int">02</number>
     <number datatype="http://www.w3.org/2001/XMLSchema#int">1</number>

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.

     <number xsi:type="xsd:int"
     <number xsi:type="xsd:int"

I think this would be useful to make RDF datatypes accessible to outside
manipulation. 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.


[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
Received on Tuesday, 15 March 2005 00:07:10 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:46 UTC