Re: namespace node implementation

On Friday, Oct 24, 2003, at 00:56 Europe/Berlin, Kay, Michael wrote:

> > the point of which is that, given the "32-bit name" which was
> > mentioned, which is close-enough to first-class, name instances can
> > serve, in themselves, to represent the information produced
> > by decoding
> > and required for encoding, and are, in themselves, a sufficient basis
> > for all operations on a closed model, without recourse to the
> > in-scope-namespace mechanism.
>
> This isn't true, because it doesn't allow you to record information 
> about namespaces that are declared, but not used in element or 
> attribute names.

_this_ claim is not true. there are other ways to represent that 
information than as "in-scope namespaces." to paraphrase an assertion 
which i recall from an earlier message, "namespaces are a disaster." 
while i agree with the sentiment, one must examine the situation in 
order to arrive at the truth of the matter.

two disasters have followed from the namespace 1.0 recommendation:

- ill-conceived notions of modeling imperatives have led to proposal 
and ratification of increasingly complex and demonstrably inadequate 
document representations. despite that the mechanisms are insufficient 
to comprehend the results of basic, foreseeable combination operators, 
they appear in successive iterations, one more complex and unworkable 
than the next.

- the 1.0 namespace recommendation failed to address "namespaced" 
document definitions while the 1.1 revision, as drafted, explicitly 
precludes complete and closed models for the general case of documents 
with a "namespaced" dtd and promotes the prefix to the status of 
universal qualifier. that without either a use case or a technical 
motivation. this must be a joke.


neither of these are inherent in the mechanism of lexically scoped 
prefix bindings. as best this implementor has been able to follow them, 
they result from misconceptions about modeling imperatives. there is no 
"truth" in that. just misfortune.

a simple thought experiment illustrates the problem. imagine two 
elements. each has a binding for the prefix "ns1", but the respective 
uri are distinct. each contains an attribute, the value of which is an 
expression which is intended to designate a path which includes 
universal names. both expressions involve the prefix "ns1". imagine an 
operator which constructs a new element which contains a single 
attribute with a value which combines the two original expressions into 
a single expression. if the model requires that qnames be expressed 
literally and interpreted in the context of a lexical prefix binding 
environment which is associated with elements and to which one attempts 
to afford indefinite extent, the operation cannot be performed. the 
resulting binding environment would be inconsistent.

the consequence is that either the granularity of the lexical contour 
must be reduced to the of the "qname", or prefixes are promoted to 
universal identifiers.

there is nothing particular to xml/xpath/xquery and namespaces in this 
result. it follows from results of research which is thirty years old. 
at that time the terms were "funarg", "free variable capture", and 
"alpha conversion". the "disaster" is not "namespaces". the problem is 
an ill-conceived and inadequate model.

in truth, it _is_ possible to define closed models which reflect the 
information encoded in namespace-aware documents _with_ QNames in 
content. in the presence of declarations, the problem is that same as 
ID/NAME/NAMES normalization for attribute values. in the absence of 
declarations, the parser cannot resolve the names, but the application 
can. the truth is that it is possible to define models which do not 
require "in-scope namespace" artifacts - neither in order to support 
combination operations nor in order to serialize correctly. every time 
the issue has come up, over the past years, i have posted examples 
which demonstrate that it is possible. usually with a request for use 
cases which go beyond the examples. as yet, there has been no response. 
i'll skip the examples this time. responses to the thought experiment 
would be enough.

>  The whole point about namespace nodes is that such declarations need 
> to be retained because the document might depend on the namespaces in 
> other ways ("QNames in content") that only the application can know 
> about.

we disagree about whether the last supposition - even if it is correct, 
does imply that retained declarations are either necessary or 
sufficient. (cf. the aforementioned examples and the thought 
experiment.)

...

Received on Friday, 24 October 2003 02:50:36 UTC