[XML-SIG] Default namespaces, attributes, 4DOM and the W3C recommendation

[Martin v. Loewis]

> Now I suppose I could have omitted the "special" prefix for "title",
> but that would make the "ownership" of "title" application-specific,
> wouldn't it?  (Meaning that since no namespace is defined, it is up
> to the application to find out what the attribute means.)

Correct.

> If we assume that "title" belongs to the "special" namespace as
> noted in the second example, how can we conveniently note this in
> the first?

By means of a default namespace? You cannot.

> Is the "special" namespace implicitly set up (due to the nature of
> the name of the element within which the default namespace is
> declared)?

No, it isn't. Any such usage would be up to the application. Of
course, since all attribute evaluation is up the application, this is
not an issue. Very few attributes are defined that have a meaning
independent of the element in which they occur (e.g. xlink introduces
some of those); for such attributes, you always _must_ qualify the
attribute with a namespace prefix.

To put it the other way 'round, any attribute that does not live in a
well-understand namespace implicitly ought to be understood in the
context of the element only. If the attribute makes no sense in the
element (considering the namespace of the attribute if given), the
application ought to complain.

> Now, none of this is specifically relevant to 4DOM, but what I'm
> trying to do is to find a convenient way of handling both of the
> above styles (or conformant variants of them) in order to be able to
> detect permissible attributes in a document using the getAttributeNS
> method on an Element, without having to find the element's own
> namespace in cases where the attribute doesn't have one.

You need to know in advance whether you are expecting an attribute to
live in a namespace or not. Both foo and prefix:foo may be present,
and may mean different things.


> How do people deal with these cases with 4DOM? Could we have more
> demonstrations in the examples directory which is distributed with
> it? The traceNS.py program seems to deliberately ignore the issue -
> some lines in the program address it but are commented out, at least
> in PyXML 0.6.5. Should anyone be thinking of extending the DOM to
> make cases like those above more easy to detect and work with?

Thinking of extending DOM is probably worthwhile, especially as a
significant share of users thinks that DOM is broken as-is (they'd
phrase it as "broken beyond repair", but I'm more
optimistic). However, any thoughts on extending the DOM ought to be
brought up to the W3C editors of the DOM specification, with DOM being
a W3C recommendation (rather than a 4Suite invention).

> Or am I doing strange things with XML that would shock its inventors
> to the very core of their collective being? ;-)

Not necessarily. It rather seems that you are overly complicating
things, and that true XML gurus would say "Why don't you just ...".

Regards,
Martin