Re: RDFa reliance on namespace declaration

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