> 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
Provided the document can be made valid per other concerns.
> or
> (b) have standalone="true".
Well, that will work, I suppose.
> Just to pick nits, attribute *normalization* refers to sorting
> out white space in attribute *values*, so I don't think that
> interacts with namespaces.
Yes, sorry; I meant attribute *defaulting*.
> 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;
Not using the draft's machinery, anyhow. A PI could put a namespace
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
-- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5)