Re: Re Deprecate/Undefined (was Request for status dump and issues check)

For what it's worth:. I need to study it further, but I _think_ the DOM can
in fact  get away with saying "We just store and manipulate whatever string
you tell us is the Namespace Identity. If there's processing that has to be
done to derive that identity from the value in the namespace declaration
attribute, that has to be done before you hit the DOM."

It looks like this can support all of the primary proposals. It matches the
Literal and Forbid modes directly. It's nowhere near as pretty in the
Absolutize mode, but it's usable, and seems to allow the DOM to escape from
its dependency on the ongoing debate... and convenience functions could be
added later, if we _do_ go with Absolutize, to encapsulate some of the
sharper corners.


Absolutization would push significantly more work into the parser and/or
application under this model. It also pushes a noticable amount of
additional work into the namespace reconciliation process which may be
needed before saving a DOM's contents as XML syntax. We already had to
consider the case where a node's declared NSURI and prefix didn't match the
declaration of that prefix in scope at this node (or where there was no
declaration attribute for this prefix, or where the prefix must be deduced
or synthesized). If absolutization is being used, best results require that
that users _DO_ explicitly manage prefixes (so that if there are two
distinct NS's in scope which absolutized to the same URI, you can tell
which one the user intended to bind to --- they may _not_ yield the same
URI when absolutized in a different context, eg if one is relative and the
other isn't) and forces the comparisons to consider absolutization as well.

Note that this seems to be workable only because the DOM has separate
storage for the namespace declaration attribute, the namespace name
actually bound to an individual Element or Attr, and the prefix which may
(or may not) point from the latter to the former. I don't know enough about
how the Infoset is thinking about namespaces to have any sense of whether
it could get away with a similar solution for Absolutize.



I still think Absolutize is the wrong answer, for reasons of:

* computational and coding overhead (as mentioned above),
* conceptual overhead (I really doubt that a novice user will understand
it, given how many of the experienced folks on this discussion have gotten
confused),
* conceptual clash with the original intent of namespaces (relative
namespace declaration can be defined in such a way that it is
architecturally consistant,, but does not mesh well with the puposes
namespaces were designed to serve),
* and fairly weak motivation (the arguments seem to be either "we might
want it in the future, if we can ever agree on what it means and how to use
it" or "we don't know that it isn't in use and we're reluctant to admit to
users that the W3C can make mistakes").

______________________________________
Joe Kesselman  / IBM Research

Received on Friday, 23 June 2000 14:03:31 UTC