Re: RDFa reliance on namespace declaration

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