- From: Mark Birbeck <mark.birbeck@x-port.net>
- Date: Sun, 18 Jun 2006 12:59:37 +0100
- To: "Ian Davis" <iand@internetalchemy.org>
- Cc: public-rdf-in-xhtml-tf@w3.org
Hi Ian, On 17/06/06, Ian Davis <iand@internetalchemy.org> wrote: > Mark, > > Thanks for the detailed reply. If I'm understanding correctly, I take > your position to be something like: "using xslt with qnames in content > is safe unless you are deliberately removing namespace nodes". Am I correct? No, far from it. My 'position' is that the problems you raise are already well known when using XSLT with languages that have QNames in attributes. There are plenty of things to watch out for when using QNames in content, but careful structuring of stylesheets can remove most of them. So it's really a discussion about XSLT that should be taking place on the XSLT lists; the only reason I feel compelled to keep responding is that the underlying assumption of your points is that we need to drop QName use from XHTML. (RDFa is just one use of QNames in XHTML 2.) Whilst of course I would 'never say never', whatever reasons there might be for not using QNames, I do not believe that the set of problems that XSLT poses is one of them. That's why I keep mentioning other languages that support QNames--people work around these (well known) limitations with XSLT 1.0 as much as possible, and XSLT 2.0 pretty much removes them anyway. > The evidence you cite is that "XSLT is used in hundreds of thousands of > applications every day, to process documents that contain QNames in > their attributes." > > I don't dispute the fact that we all use a lot of XSLT. But I don't > believe that qname in content safety is anywhere specified in the XSLT > recommendation... It's not! Who said it was? > ...and, as I pointed out, it is explicitly stated that > prefixes may be changed by processors. I dealt with that Ian, and pointed out your mistake...the XSLT 1.0 spec explicitly states that prefixes can be changed on elements and attributes, when created using xsl:element and xsl:attribute (you quoted that section yourself). It does *not* say that prefixes can just be abitrarily changed at some point in the processing. And in fact, it does say that when creating the result tree an element node will have a copy of all namespace nodes that were present in the original, which therefore includes all the prefixes. > The reason few errors are > encountered are primarily through the use of conventions for namespace > prefixes such as foaf, cc, xsl, xs, etc. That's not completely true. Some people are also very careful in how they construct their stylesheets. > An application is, of course, free to choose any namespace prefix it > desires. Try, for example applying this stylesheet to the xml that follows: > > [snip] > > I find in MSXSL and in XSLTPROC that the qname in the property attribute > has changed it's binding. I'd be interested to see your results. Yes I get the same results as you do, when using your stylesheet. But as I've said, all of these problems are well known, and certain of them have solutions. In this case simply remove the xmlns:a from the root of the stylesheet, and change your second template to this: <x:p> <xsl:attribute name="ex" namespace="http://example.com/bar#">test</xsl:attribute> <xsl:copy-of select="@*" /> <xsl:copy-of select="namespace::*" /> <xsl:copy-of select="*"/> </x:p> You could even do the same for the 'p' element. In general, when writing documents that deal with many namespaces, letting the XSLT processor decide on the prefix is not a bad idea, since the prefix used for elements and attributes does not matter in the way it does for content. As I keep saying, this is a discussion that should be taking place on an XSLT list, perhaps under the title of "how do I ensure that namespace prefixes are preserved when using QNames in attributes", not in an RDFa discussion themed "why RDFa should not use QNames". > On 17/06/2006 17:31, Mark Birbeck wrote: > > However, since the theme of this discussion is that we need to avoid > > using QNames in attributes--and invent alternatives--then it's > > obviously important to continue with the XSLT-specific discussion > > here. > > Or we can switch to SAX pipelines, or XML databases, or any system that > may parse, manipulate and then serialize an XML document. I really think we've gone as far as we can with this. Sure, there are problems with XML processing tools when using QNames in content, but the problems are well known. Many of these problems can be worked around with careful design, although increasingly the tools themselves are becoming geared towards handling the issues. For example, XSLT 2.0 can be made aware of the type of attribute content in the way that for example, XML Schema is. This is obviously because QNames are used so widely in XML languages. My conclusion is that the awkwardness of using XSLT 1.0 to process XHMTL documents that contain QNames does not justify dropping the use of QNames as a scoping mechanism, especially since QNames are used so widely in XML languages. Regards, Mark -- Mark Birbeck CEO x-port.net Ltd. e: Mark.Birbeck@x-port.net t: +44 (0) 20 7689 9232 w: http://www.formsPlayer.com/ b: http://internet-apps.blogspot.com/ Download our XForms processor from http://www.formsPlayer.com/
Received on Sunday, 18 June 2006 11:59:43 UTC