- From: Mark Birbeck <mark.birbeck@x-port.net>
- Date: Sat, 17 Jun 2006 17:31:11 +0100
- To: "Ian Davis" <iand@internetalchemy.org>
- Cc: public-rdf-in-xhtml-tf@w3.org
Hi Ian, In my view this discussion is really about using XSLT with XML languages that use namespaces in attributes, and should really be taking place on an XSLT list. Everything you have said would apply, for example, to manipulating an XML schema that contains the following: <xs:schema ...> <xs:element ref="xf:model" /> <xs:element name="xf:model"> ... </xs:element> </xs:schema> or manipulating an XSLT stylesheet, or an XForm. 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. On 17/06/06, Ian Davis <iand@internetalchemy.org> wrote: > On 17/06/2006 00:06, Mark Birbeck wrote: > > Firstly, this is not how XSLT behaves, Ian. XSLT doesn't actually know > > anything about namespace *declarations*--what it deals with are > > namespace nodes. If you declare CC on the <html> element, then you > > will have a namespace node for CC on *every* element in the document. > > At any point in the tree you can copy all of the current in-scope > > namespaces. That's what you did when you used xsl:copy-of, and that's > > why you *should* get CC and FOAF namespaces copied through onto <head> > > and <body>. That's what I get in all of the XSLT processors I have > > tried. > > This is missing the original point of this thread. I'll come to the original issue in a moment, but the one we have been discussing is still an important one, and it would be good to resolve it one way or another, and not just move on. You said explicitly that identity transformations caused namespace prefixes to be 'lost' if the prefix wasn't used in some element or attribute. I replied that: * from reading the XSLT spec I would not expect to see the probem; * in my daily use of many XML languages that use namespaces in attributes I don't actually get this problem; * using your stylesheet and sample document I was unable to reproduce the problem. It would be good to have some resolution on this, since if there really is a problem, it's pretty serious. So, the question remains; do we *lose* namespace declarations when, for example, copying fragments (as in your example), when we have a situation where those declarations involve prefixes that don't appear on any element or attribute in the document? I'm saying that I don't think we do, and that if you do lose those namespaces we need to seriously look into this. (There are situations where you have to explicitly copy namespaces, but that's different, and I'll come to that.) Anyway, let's look at the 'main' topic, in parallel with this one. > It's not the namespace nodes that I'm interested in, but the specific > prefixes that are used in the resulting XML serialization and their binding > to the CURIEs/qnames in attribute values. This question is slightly different to the other one; we're asking is it possible for an XSLT transformation to *change* namespace prefixes, in such a way that we in effect lose prefixes that we need? The answer is an unequivocal...yes and no. :) Before I explain that, I'll just quote the rest of your post, and then I can take everything together: > Can you reference the part of the XSLT specification that requires > processors to preserve the prefixes of namespaces in the serialization? > > There's no mandate to do so for xsl:element or xsl:attribute. For > example section 7.1.2 of XSLT1 [1] says: > > "XSLT processors may make use of the prefix of the QName specified in > the name attribute when selecting the prefix used for outputting the > created element as XML; however, they are not required to do so." The reason I said "yes and no" is because I believe you've mixed up two different things here. On your first point ("Can you reference the part...")--why should the spec necessarily talk explicitly of preserving namespace prefixes? If we talk of copying a fragment (as in your previous stylesheet example), why would the namespace prefixes be changed by the processor? The fragment is, after all, just being 'copied'. I could therefore ask the question the other way round, could you point to the part of the spec that allows prefixes to be changed to arbitrary values when being copied? Your second point ("there's no mandate to do so for xsl:element or xsl:attribute") sounds like you think this is where prefix changing is allowed for, but this part of the spec really doesn't deal with *changing* prefixes in the way you assert; what you have quoted concerns the prefix used for a *newly* created element or attribute, not other prefixes that might already exist on the element. All the spec is saying is that when new elements and attributes are being created (i.e., when you use the instructions xsl:element and xsl:attribute) the processor is not obliged to *re-use* the prefixes that already exist. But to be very clear, that does *not* mean the processor simply drops the prefixes that it doesn't 'use'. So, in this example: <a:b xmlns:a="abc"> <a:c /> </a:b> if you were to use xsl:element to create a copy of the element <a:b> (rather than using xsl:copy), it might look as follows: <xsl:template match="a:b"> <xsl:element name="{local-name()}" namespace="{namespace-uri()}"> <xsl:apply-templates /> </xsl:element> </xsl:template> It is true that you could feasibly get alternatives such as this: <a:b xmlns:a="abc"> <a:c /> </a:b> or this: <ns1:b xmlns:ns1="abc"> <ns1:c/> </ns1:b> However, when creating elements in this way (using xsl:element), or even when creating elements inline and then attaching attributes, if you are dealing with documents that contain QNames then it is a pretty good idea to copy 'current' namespaces through. How you do it depends on what you are doing, but a simple way is to do this: <xsl:template match="a:b"> <xsl:element name="{local-name()}" namespace="{namespace-uri()}"> <xsl:copy-of select="namespace::*" /> <xsl:apply-templates /> </xsl:element> </xsl:template> (Something like this is pretty standard practice if you are transforming XSLT or XML Schema, and we do this in our work all the time when transforming XHTML that contains XForms. Note that it is copying 'current namespaces' and not namespace declarations.) Now, if we modify our original mark-up to include a namespace that we want to use inside an attribute: <a:b xmlns:a="abc" xmlns:cc="cc"> <a:c /> </a:b> the previous XSLT might give this: <a:b xmlns:a="abc" xmlns:cc="cc"> <a:c/> </a:b> or this: <ns1:b xmlns:ns1="abc" xmlns:a="abc" xmlns:cc="cc"> <ns1:c/> </ns1:b> But note that either way, the CC namespace is passed through intact. > Perhaps I'm missing something? With respect, I do think part of the problem is mixing different XSLT concepts. And if I might say once again, XSLT is used in hundreds of thousands of applications every day, to process documents that contain QNames in their attributes. 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 Saturday, 17 June 2006 16:31:23 UTC