wd-xml-names: resolve the element name in the scope of its containing element.

[Tim Bray]

At 05:00 PM 8/11/98 -0400, John Cowan wrote:

[interpreting james anderson]

>Here's my take on it.  Suppose you have the fragment:
>
>	<foo:a>This is <b>mixed</b>content</foo:a>
>
>where "foo" is not a previously declared prefix.  One must then consult
>the DTD to see whether the element declaration for "foo:a" contains
>a default (or fixed) value for the "xmlns:foo" attribute.  If not,
>a namespace constraint has been violated.

You go on to raise the issue in greater detail, but it is clearly
the case that the rules have to be spelt out.  For example, it's
obvious to me that for a non-validating parser, if he hits <foo:a>
and hasn't seen an xmlns:foo= in his encestry, the situation is
broken.  Should the spec mandate that in this case, a conforming
program has to go and fetch any and all external parts of the
DTD to make sure there isn't a default declaration?  Good question.
I think the answer has to be "no", thus putting the onus on the author
either to (a) use a validating processor or 
(b) have standalone="true".

>In short:  DTDs don't just serve validation, they serve attribute
>normalization as well, and only after attributes are normalized
>can the full set of namespace declarations be determined.

Just to pick nits, attribute *normalization* refers to sorting
out white space in attribute *values*, so I don't think that
interacts with namespaces.

>Paraphrase:  "The declaration of a namespace could be placed in the
>parent element, such that the prefix-to-URI mapping affects only
>its children, and not itself."

Gosh, it's nice to have you here to interpret.  If we were going to
do that, then you couldn't have namespaces on the root element; so
you'd need two *separate* things, one for content-only and one
for self+content.  Maybe the convenience of the content-only
binding would make up for the pain of having to handle two different
kinds of declarations; so far the WG hasn't bought that.

><strong>All these considerations fall to the ground if namespace attributes
>*cannot* be defaulted from the DTD (unlike other XML attributes).
>The draft is silent on the point.</strong>

Obviously they can, because an XML processor is required to provide
defaults, but not to tell the app that they are defaults.  So there's
no difference in principle between a provided and a defaulted 
attribute. -Tim

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)