Comments on Section 2.6 of XML-Namespaces

[Rick Jelliffe]

-----Original Message-----
From: Andrew n marshall <amarshal at usc.edu>


>> As for as your particular example goes, there is "no guarantee from the
DTD
>> that they mean the same thing" because there is no mechanisms built
>> into raw XML DTDs to provide such a guarantee: in fact this is why
>> namespaces are needed--to make it clear that an attribute in one
>> element type is kin to another.

> The element declaration is that guarantee.  XML, with the inclusion of the
> namespace specification at the element level, describes a way to trace
each
> element back to an element declaration from which I can compare whether or
> not any two elements are related.  By this, I am guaranteed that the
> attributes of each element of the same element declaration have the same
> possible attributes and are complete enough to be useful with it specific
> application.

Namespace declarations apply to multiple element types. You probably
could get the same result using HyTime architectural forms definitions
and sticking #FIXED attributes on each individual element type declaration
in the markup declaration, it is true. But namespaces need to work in
documents without XML markup declarations, and it needs to be terse
enough so that it can be set once. (I certainly agree that there are much
more interesting things lurking under the surface of the namespace
issue, but no-one seems to dispute that.)  So element type declarations
cannot be a guarantee of anything.

> However, as soon as you allow elements to be broken up into their
> individual attributes, this gaurantee goes away.  Attribute "hijacking"
> makes it impossible to maintain the relationship between attributes of a
> single element, and impossible to maintain the relationship between the
> attributes and the child elements/content.


I dont think I agree with your ideas of "hijacking". An attribute is
whatever
the designer has said it is, for better or worse. E.g., if a document type
designer says that all elements types will have an attribute which gives
the line number of the element type declaration in the original document,
then that attribute has nothing to do with the element type itself, and
everything to do with the artifacts of the declaration of that type. Such
an attribute has its meaning without any reference to any particular
element type being defined. So some attributes are highly coupled to
their type, some are highly uncoupled.

But perhaps you might agree with me that the way to prevent this
problem (i.e., where an attribute in one element is named partially
using another element name) is for the original designers of the
schema to use explicit namespace qualifiers for all attributes
which are not strongly coupled to the element type. These are
the particular attributes which perhaps are most likely to be
detached.

> Actually, if you look at the details of the XLL spec (Part 7, second
> paragraph), attribute remapping is limited to the XLL specific attributes.

...

That is why I prefaced my comment with "And in any case, in your
particular case of hrefs, the XLink draft  provides an attribute
remapping feature."

Rick Jelliffe


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/
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)