Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Fw: Namespaces
 I asked: >> Is it possible to recast the namespace recommendation as a transformation >> from an XML tree with 'xmlns' attributes and '...:' prefixes into a tree >> which doesn't have them, but with modified element and attribute names, >such >> that the semantics of the resulting tree under the rest of the relevant >> recommendations (ignoring namespaces) is preserved? One would of course >have >> to pass the DTDs (or other schema files) through the same transformation. And got - self contradictory responeses! For example: Ronald Bourret <rbourret@i...> wrote: > This transformation is possible, but I don't think it buys you anything. Except compatibility with current APIs - the ability to add a namespace processor on top of SAX, say, _without changing the interface_. But let this slide... >For those of you who have forgotten the original question (I had to look it >up), it essentially asks: > >Is the relationship between "good" and "a" the same in <good a="1"/> and ><good foo:a="1"/>? > >Expansion has nothing to do with it. Which is contradicted by the very next sentence: >The namespaces spec introduces the >concept of a "global" attribute, which doesn't exist in XML 1.0. AHA! So the namespaces proposal _DOES_ go beyond simply qualifying names with URIs! Which means I _CAN NOT_ transform an XML document with namespaces into a document without namespaces (but with extended names) and achieve the same semantics. Let me clarify what I mean by that: Suppose I have an XML processing system, with some XML input files (including DTDs, schema definition files, input files, stylesheet files, whatever). Let us assume that they (or some of them) use namespaces as per the current draft. I run the system and get certain effects, including possibly some output files which again may use namespaces. Now, I transform all the input files to stop using namespaces. Instead I transform them to something like James' extended names format. I hack the XML system to _not_ do namespace processing, if necessary, and re-run it on the input files. I'd expect the effects to be identical and the XML output files to be the same the original run's output files, after compatible name extension. If this were to hold, namespaces would have been simple, and truly orthogonal to all the other standards. "This turns out not to be the case", but I can't get anyone to admit it - so I can't get a straight answer to _why_ this isn't the case. Why is this impossible? Because "prefixed attributes are global". The XML system handles them differently based on the fact they are _prefixed by a namespace_. In the second run _no_ attribute is prefixed. Note that the _uniqueness_ of the names wan't hurt; "foo:a", "a" and "bar:a" are still different. It is just that none of them are "namespaced". >(For a >discussion of global attributes, see Andrew Layman's summary at >http://www.lists.ic.ac.uk/hypermail/xml-dev/9902/0027.html.) I re-checked this and as far as I understand Andrew makes a pretty good case that there is no such thing as a global attribute - at least, in DTDs there isn't. Now, if global attributes are necessary, or all attributes should be global, or whatever, is something I'd be happy to see discussed. But why does this have to be dragged into the namespace issue? Why isn't it defined so it would survive the transformation I described above? Move this "global attribute" business to the DTD or Schema WG where it belongs! >You can tell which attributes are global and which are local by looking for >prefixes: global attributes have a prefix and local attributes don't. That's one answer - a way to know which is which without looking at a DTD. IMVHO, this isn't worth the price. Look at the amount of misunderstanding this caused! Not to mention the implementation issues - without being able to do the transformation I described above, all the XML APIs have to be reworked, and so on... No namespace unaware application will be able to survive the transfer to the namespace-aware world. Surely there's a better reason for such a profound decision? >So, your question boils down to: "Is the relationship of good to a the same >as the relationship of good to foo:a?" James rightly side-steps the >question, because you are asking about the relationship between an element >and two *different* attributes which *happen* to have the same name. No. First, "a" and "foo:a" are _not_ the same name. Second, it would have been the same question if I used "a" and "foo:b". I now understand that the latter is "global" and therefore these relationships are _not_ identical. I still reeling from the shock. > This question has nothing to do with the namespaces spec (how the names of these >attributes are expressed -- prefix form, Clark notation, etc. -- is >irrelevant) <censored/> How can you say that this has nothing to do with the namespaces spec when it is (i) introduced in this very spec and (ii) relies on the attribute having a namespace prefix in order to declare it as global? >Does your head hurt any less now? Just about to bust at the seams, thanks :-) Even James, which normally admirably clears things up in one or two well-designed sentences, left me confused. To my original question (is it possible to do a transformation...) he answered: > Yes. The transformation changes some element type names and attribute > names from strings to structured objects that contain a URI and a > string. Which is _not_ what I had in mind - I was specifically referring to a _textual representation valid under the non-namespaced XML-1.0 spec_. But since one can convert qualified names to text - he has given a sample in his paper, after all - lets continue... >> such >> that the semantics of the resulting tree under the rest of the relevant >> recommendations (ignoring namespaces) is preserved? >I don't understand what you mean by "preserving semantics". In the sense of equivalence I defined above. That is, namespace-semantics(XML) == non-namespace-semantics(extended-names(XML)). >> One would of course have >> to pass the DTDs (or other schema files) through the same transformation. > Why? DTDs are used only at the pre-transformation stage. WHAT? How can DTDs be pre-transformation? If a DTD refers to 'foo:a', where 'xmlns:foo="my:uri"', and my document contains 'bar:a', where 'xmlns:bar="my:uri"', it won't match since 'foo' != 'bar'? Surely I misunderstand? >I would expect >a future XML Schema language to operate purely on the >post-transformation tree. Well, that helps a bit, though I don't see why existing languages can't share the privilege... >> if "all" the namespaces do >> is prefix the names with a URI, >Qualify not prefix. A URI-qualified name is not a string but a >URI/string pair. Fine. I'm still trying to see how can one say that "all" namespaces do is "qualify names" - which with appropriate textual representation can become "prefix the names" - and still say that they introduce global attributes: >> why should the relationship between expanded >> names be different then that between "normal" names? >Because it's URI-qualified and therefore capable of independent >interpretation. A URI-qualified name is a different kind of object from >a "normal" name. Hardly a sufficient answer. What is the _benefit_ of distinguishing between the two? As opposed of declaring global attributes in a DTD, or whatever? >> Anyway, how come >> it is "application dependent" >I said it was dependent on other applications *or other specifications*. Whatever. I still don't see what applications have to do with it. _From the XML standard point of view_, there's a certain relationship between attributes and elements. This relationship might well be "the application may do anything it wants". With regard to URI-prefixed attributes, the namespaces XML makes it clear that this relationship is _not_ the same as that for unprefixed attributes. Now how much sense is in that, if both relationships are "the application can do whatever it wants"? >> don't DTDs and schema language have a lot to >> say about it? >DTDs don't have anything to say about it because they don't know about >namespaces. I would expect a namespace-aware Schema language to have a >lot to say about it. Why should the DTD spec be "namespace aware" if the transformation I asked about exists? Shouldn't I simply transform both the DTD and the document, then check validity? For that matter, why should _any_ XML standard be "namespace aware" - couldn't the same apply to them all? I can see how namespace patterns might be useful in XSL, but that's a rather exceptional case. Why wasn't the DTD spec extended to handle global attributes (regardless of namespace issues) instead of sneaking them in the namespace spec? Global attributes make the same amount of sense for non-prefixed attributes within a single XML language. This is the root of the problems here - _what is the benefit gained from placing this in the namespace spec_? Is there one? Is it worth it? Can we revoke it? Again, I could be very wrong here - when it seems to me everyone else is contradicting himself, it is high time for a reality check. Help? Oren Ben-Kiki xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...) 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
