Joseph Kesselman wrote:
>
> >"An element is said to be within the scope of the binding"
>
> Would "within the scope of a prefix-to-namespace binding" help?
>
not really, because the next clause asserts a definition which is at odds with the standard definition.
the problem is that being in the scope of an identical binding is not the same as being in the scope of a binding.
for the purposes of normalization and serialization, the dependancy established by "namespaces in xml" must be reversed. that is, the logical requirements of
serializing/normalizing are that "in the scope of a binding" mean that "some prefix is bound to the namespace name", not "the prefix is bound to some namespace
name". anything else elevates the prefix to the universal name identifier, which contradicts the intent of "namespaces in xml".
> >the consequence of the draft's inversion is that the it suggests that,
> >where the apparent binding (after all there _is_ a binding) conflicts
> >with the contingent binding which would be imputed from the incidental
> >element identifier, it is necessary to introduce a new binding.
>
> This is correct. Remember, the DOM does not require that all namespace
> declaration attributes be present.
i'm not really arguing from "the dom", but from logical necessity. from which it follows that neither prefixes nor namespace attributes must be present. they
can both be synthesized when serializing/normalizing.
> Thus, there may be implied bindings,
> which may conflict with explicit ones. The namespace fixup algorithm is
> about finding and "realizing" those; the namespace lookup algorithm
> behaves "as if" fixup had been performed.
i understand the algorithm. i am surprised that the approach to eliminating overconstrained assignments if is to change the namespace attribute set (that is to
add one) rather than to change the prefix.
>
> Yes, if a different prefix happens to be available which is bound to the
> same URI, changing the prefix would suffice. I know this was considered
> during the design of the namespace fixup/lookup algorithms, and various
> trade-offs were discussed; I'd have to re-read the pseudocode to refresh
> myself on what the current status is and why.
i'm curious.
...