Namespace questions

[james anderson]

David G. Durand wrote:
> 
> In brief answer to your continuing comments on this issue, the
> namespace spec currently does _not_ make the restrictions

i believe mr. durand may have misunderstood the context of my remark on
"effective qualification". (was it that passage?) while the notion of
"effective qualification" may not appear in the wd, it applies nonetheless to
the application domain in which the question was posed.

> nor
> have the implications that you would like.

we disagree. you may not see the implications. i do.
i understood the question to have been posed with respect to an application
which is to operate on data of which the encoded form may contain qualified
names, and where the prefixes may vary from document to document. such an
application is going to require mechanisms of the kinds i describe in order to
produce predictable results.

there will be many such applications. i leave the implications open.

> It allows applications
> that _wish_ to, to disbamiguate names based on a prefix. It does

i trust that the context of the discussion leaves no doubt, that that is the
kind of application with which my remarks have been concerned.

> not make _all_ names qualified,

for which applications, even names which conform to "NCName"'s in their
encoded form will need be comparable with those which are qualified. if one
does not identify the region of the namespace which is implied by the lack of
a prefix when decoding, the results are unpredicatable.

> nor does it affect DTD or link
> processing, or any other process that already uses GIs.

i don't understand this.

since both of these processes depend on name identity it's hard to see how a
standard which specifies how names are encoded does not - at least in terms of
the appearance of the data upon which they operate -  affect them.

one can't very well send a server an uri which contains an xpointer in its
fragment identifier and then say "hey, now you figure out what the prefixes
were supposed to mean. good luck."

> The kinds of things you are advocating may be useful (and they may
> not), but they are currently not on the table, because they have so
> many implications for the rest of XML.

which is unfortunate; and exactly why i discuss them.

and please take my remarks as "reporting" rather than "advocating".
i'm just recounting what i've had to do to fill out the standards to get
things to work.

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)