Re: XML result format and datatypes

On Fri, 2005-02-18 at 12:26 +0000, Damian Steer wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> (I'm don't think this is an essential feature, but I felt it was worth 
> mentioning)
> 
> The results binding format doesn't type datatyped literals in a way xml 
> schema-aware tools can use.
> 
> Use case: sorting results.

The WG is thinking about this in terms of possibilities it might go in
the query language.

> Example (abbreviated):
> 
> <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>
> 
> Stylesheet (abbreviated again):
> 
> <xsl:template match="results">
>    <xsl:for-each select="result">
>      <xsl:sort select="number"/>
>      <xsl:value-of select="value"/>
>    </xsl:for-each>
> </xsl:template>
> 
> Value 'second' comes before 'first'.
> 
> Using xsi:type="xsd:int" in the result format would enable schema aware 
> tools (such as Saxon-SA) to perform more useful processing.

That makes sense.

> I appreciate the relationship between rdf and xml datatypes is not 
> straightforward, but it would certainly be useful to process values 
> correctly when possible.
> 
> Suggested resolutions:
> 
> 1) Assume the user typically knows the type, and so will use casting
> (xsd:int(number)).

They usually will since they normally wrote the query, however a single
query may return for the same variable a mixture of RDF Terms so that
cast would need protection with a check.  If the typing was built in,
the XSLT would be able to skip that check.

> 2) Include both datatype and xsi:type attributes where the rdf datatype 
> maps to an xsd type: <number datatype="..." xsi:type="...">

If xsi:type is added, it would have to be only in addition to and not
replacing datatype.

However if that was to be useful, the VBR XML format user would have to
be able to expect xsi:type attributes to be present as being optional
would mean the need for yet another check.

So that then means, when would xsi:type be able to appear?  Since the
conversion from RDF URI datatypes to xsi:type qnames is not necessarily
defined or even possible, it would at the very least, be possible only
for those XSD types that SPARQL itself supports or those in XSD that
have a defined URI<>qname mapping (in some W3C REC say).

So then the rule would be, when generating a datatype="uri" for a W3C
XML Schema Datatype, you must emit xsi:type="qname" for the matching
qname.

The further question of whether any other xsi:type is allowed, I'd see
as open for either forbidding - as it would have to be known by some
other non-sparql mechanism - or allowing in the interests of
extensibility.

Aside: Would also have to distinguish a variable with a URI RDF Term
value and one with a RDF datatyped literal with the datatype xsi:anyURI.

Dave

Received on Wednesday, 23 March 2005 15:19:06 UTC