[XML-SIG] Element.localName, Attr.localName

[Martin v. Loewis]

"Fred L. Drake, Jr." <fdrake@acm.org> writes:

> Because I've said this is only an XML 1.0 document only; it happens to
> attributes that would be namespace declarations and prefixes if
> namespace processing were active, but it isn't.

What else could it be? There is only one version of XML.

> Er, no, there are no namespaces because this is only an XML 1.0
> document; the namespaces recommendation does not apply.

The document does conform to the namespaces recommendation, though.

>  > That is not true. In DOM Level 2 and onwards, that should be
> [...list omitted...]
> 
> If namespaces are active, yes.

What do you mean by "active"? Namespaces cannot be active or
passive. A document can either conform to the namespaces
recommendation or not conform to it, see

http://www.w3.org/TR/1999/REC-xml-names-19990114/

This document does conform. Furthermore, an application can be aware
or not aware of the namespaces - but this is independent of the
document.

> Like I said, there are no namespaces.  ;-)

I hear you say that, but I cannot understand what you mean. The
namespaces are there, even if you are unaware that they are.

> Ok, so if namespaces *are* active, what should be the localName of the
> <doc/> element in my example?  Or even this document would do:
> 
> <doc/>
> 
> There is nothing there to give a namespace to the <doc/> element; what
> should localName be?  

That is easy to answer: There is no default namespace (5.2), 

"If the URI reference in a default namespace declaration is empty,
then unprefixed elements in the scope of the declaration are not
considered to be in any namespace."

So the localName is u"doc".

> Note that the createElement() vs. createElementNS() distinction
> isn't helpful here, either, since there's nothing in the LS spec
> that gives guidance on which to use in this case, or even requires
> that either is used in any case -- that's left as an implementation
> detail.

And rightly so - the LS spec does not even claim that you can
implement it merely by using the DOM API.

Instead, the real question is how the loader should operate when the
"namespaces" feature is off. I don't think the spec currently says;
most likely, the authors of the spec assume that the loader fills out
the namespace attributes, anyway. They are probably wrong in this
position - the loader then has no way to process a document
meaningfully that is not namespace conforming.

Regards,
Martin