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':
fn:get-namespace-uri-from-Qname(@property);
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:
fn:get-namespace-uri-from-QName(xs:QName(@property));
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
'creator'.
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:
fn:get-namespace-uri-from-QName(@property);
Regards,
Mark
[1]
http://www.w3.org/TR/xquery-operators/#func-get-namespace-uri-from-QName
[2]
http://www.w3.org/TR/xquery-operators/#func-get-local-name-from-QName
[3] http://www.w3.org/TR/xquery-operators/#casting-to-QName
Mark Birbeck
CEO and CTO
x-port.net Ltd.
Download our XForms processor from
http://www.formsPlayer.com/