RE: namespace node implementation

I thought this discussion was about how to implement the current
specifications concerning namespace nodes. You seem to have changed the
subject, and to be talking about alternatives to the current specification,
and indeed to be engaging in philosophical discussions about the merits of
namespaces in the XML world view.

I'm afraid I can't cope with all three levels at once. You'll need to be
clearer about which plane we're on.

Michael Kay

> -----Original Message-----
> From: james anderson [mailto:james.anderson@setf.de] 
> Sent: 24 October 2003 07:51
> To: www-ql@w3.org
> Subject: 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.)
> 
> ...
>