[
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
>"sane"
>
><x>
><x xmlns:x="data:,x" select="x:y[.='x:y']"/>
><x xmlns:x="data:,y" select="x:y[.='x:y']"/>
></x>
>
>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']"/>
></x>
>
>
>
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>
<x select="{data:,x}:y[.='{data:,x}:y']"/>
<x select="{data:,y}:y[.='{data:,y}:y']"/>
</x>
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']"/>
</x>
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
content).
cheers,
Burak
--
Burak Emir
http://lamp.epfl.ch/~buraq
|
