OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] XML-aware programming language?

[ Lists Home | Date Index | Thread Index ]

David Carlisle wrote:

>  If this requirement had been foreseen, I am sure the rec would have 
>  included expanded names {iri}:localName, thereby *forcing* implementors 
>  that want to be conformant with the spec to add a preprocessing run that 
>  expands all prefixes.
>I don't necessarily disagree with you, but essentially you are saying, if XML
>Namespaces had been defined differently, things would be different.
>I doubt _anyone_ would disgree with that:-)
I actually was saying, change it for the better now, and things will be 
different. And people still disagree with that :-)

>Whether or not it's acceptable now, 6 years on, to define core XML
>transformation/Query technologies that only support an "easier" subset
>of XML Namespace conformant documents is essentially a marketing issue not
>a technical one, so not something that I'm prepared to comment on (I may
>have an opinion, but I'd just be guessing based on zero knowledge).
My concern is not marketing, but the itch is very real, and fixing it 
will help very much and I think a committee with the ambition of playing 
standards organization would gain credibility by fixing ugly specs.

>>In that case, very easy to specify a postprocessing run that makes the 
>>XML sane again.
>again it depends what you are post processing with. As Mike Kay just
>commented it's not at all clear if, given the current draft spec, Xquery
>has enough of a handle on generation of namespaces to transform a
>document such that any required namespace declarations appear at the top.
>XSLT can do this if there are no Qnames in content, but if there are,
>I don't think either language can make this post processing run.
>If you are moving  namespace declarations to the top, you have to be
>prepared to change prefixes in the case that there are clashing
>definitions. If your QNames-in-content are, say, an XPath expression,
>that means you need a full XPath parser in order to be able to discover
>just exactly where the Qnames are, and what prefixes they have.
>What "easy specification" did you have in mind to make this XML document
><x xmlns:x="data:,x" select="x:y[.='x:y']"/>
><x xmlns:x="data:,y" select="x:y[.='x:y']"/>
>so ending up with something like
><x xmlns:x="data:,x" xmlns:y="data:,y">
><x select="x:y[.='x:y']"/>
><x select="y:y[.='x:y']"/>
The idea is to get some intermediary representation (well-formed xml, 
but not well-formed xml+namespaces)
Yes this is tough, because in xslt, maybe also xquery, you need to parse 
xpath. but it can be done.

<x select="{data:,x}:y[.='{data:,x}:y']"/>
<x select="{data:,y}:y[.='{data:,y}:y']"/>

Here I have effectively destroyed the prefixes, so my result could only be

<x xmlns:ns0="data:,x" xmlns:ns1="data:,y">
<x select="ns0:y[.='ns0:y']"/>
<x select="ns1:y[.='ns1:y']"/>

but that's fair enough, given that you can make the algorithm keep track 
of the prefixes it encounters.

Mind you, if the namespaces rec said {iri}:localName is fine, the 
transformation would just stop at the intermediary form.

But you are right in that parsing the XPath is a price to pay (for 
sanitization of XSLT at least). For XML Schema it should be a bit easier.

>If you want to say that you just want to ban the first version, OK: as I
>said above that's a defendable position, and let the market decide if
>that's acceptable, but I don't see how you can say that you can "easily"
>normalise the documents that you just banned into a form that would be
>acceptable to the new order.
For any given domain (Schema, XSLT, etc) that can interpret the content 
(parse it), it is straightforward to give this processing, because if 
you use the QNames, then you know where they appear. A kind of 
source-to-source transformation.

I am not sure if anybody really auto-generates XSLT with clashing 
namespace declaration. I think those people will never want to use any 
software I write anyway, and continuing this mess to make them happy is 
a questionable way of promoting an interoperable data format.

My hypothesis is that anybody who can come up with an instance that uses 
namespace prefixes in content (or generate it), can also come up with an 
instance that is sane. (For generated XML, we are talking about the 
programmers of the generators). For them, it is easy. There is no 
one-fits-all sanitization for prefixes in content (or rather: qnames in 


Burak Emir



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS