W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > March 2004

RE: extracting statements from RDF/XHTML

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Wed, 17 Mar 2004 10:53:28 -0000
To: "'Dan Connolly'" <connolly@w3.org>
Cc: "'RDF in XHTML task force'" <public-rdf-in-xhtml-tf@w3.org>, "'Jos De Roo'" <jos.deroo@agfa.com>
Message-ID: <005001c40c0e$14e25830$0d01a8c0@W100>

Hi Dan,

Sorry for the delay in replying.

> I saw you chatting with Jos and a few others
> about an XSLT transformation from that syntax
> to triples.
> Dom brought up an issue about XSLT and Qnames 
> http://www.w3.org/2004/03/05-swbp-irc#T09-32-> 39
> I'm curious 
> how that's handled too.
> Do you have details 
> to share?

Yes, it seems that everyone is concerned about QNames! I must admit, I
wasn't worrying about it in my proposal, since it seems pretty trivial
to crack a string open and get out a namespace and local name. From a
purpose-built parser point of view it's easy, and from a GRDDL point of
view there are a few ways to do it, but the one I favour would involve
just adding two functions to an XSLT stylesheet. When I have a minute
I'll extend the demo that I did in Cannes to incorporate the two
required functions, and also change it so that the output is not N3.

Just whilst I'm here, I'll touch briefly on how I was planning to do
these functions, and that is to use the same names and parameter
signatures as a couple of the new QName manipulation functions in the
proposed XPath 2.0 [1] [2].

Note that although the functions mentioned actually take xs:QNames as
their parameters - a type which obviously doesn't exist in XPath
1.0/XSLT 1.0 - this is not a problem, since an xs:string can be cast to
an xs:QName [3], which effectively hides the problem for us. So, if we
had the RDF/XHTML mark-up:

  <meta property="dc:creator">Mark Birbeck</meta>

in 'real' XPath 2.0 we would do the following to get the namespace URI
that corresponds to the prefix 'dc':


If we had not loaded any schemas, then @property would only be a string
value, not a QName, but this is covered by promoting the string to a
QName, and is therefore equivalent to this:


The QName is created by taking the string "dc:creator" and looking at
the prefixes that are 'in-scope', so the QName would have a URI part
made up of the namespace obtained from 'dc', and a local name part of

However, since we don't have objects of type QName in our current
XPath/XSLT set-ups anyway, then our functions will only operate on
strings. In which case our usage will 'look' exactly the same as the
'correct' usage in a full XPath 2.0 implementation:




[3] http://www.w3.org/TR/xquery-operators/#casting-to-QName


Mark Birbeck
x-port.net Ltd.

Download our XForms processor from
Received on Wednesday, 17 March 2004 05:54:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:17 UTC