Fw: Namespaces

[Oren Ben-Kiki]

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 at ito.tu-darmstadt.de> 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 at ic.ac.uk
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 at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)