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

At 11:04 2000 06 08 -0400, keshlam@us.ibm.com wrote:
>Before we jump on the Deprecate/Undefined bandwagon,...
>
>I need to look at it again, but I think the DOM could get away with saying
>something like:
>
>"A Node's namespaceURI attribute is treated as a string, which yields the
>right results for the absolute URI+locator values which have been declared
>the Real Identity of a namespace. Since the handling of relative syntax is
>currently undefined, individual implementations can decide whether to
>accept it, reject it, or warn about it.  However, if absolutize is
>introduced later,  that additional processing should happen at the
>parser/application layer, since that's where the decision is made about
>what the identity of this node's namespace should be. We might want to
>provide some convenience functions at that time, but our basic model of
>operating in terms of the Namespace Identity shouldn't have to change."

The Deprecate/Undefine choice leaves the Infoset with one of the 
following two choices:

1.  define what the infoset is when a deprecated relative URI is
    used [which is precisely what started this whole discussion,
    so is unlikely to happen], or

2.  say that a document containing an nsattrib whose value is a
    relative URI has no defined infoset.  This works, but may be
    too close to the "forbid" option for some folks.

If I understand your "if absolutize is introduced later" scenario,
you are saying that the absolutization happens at the lowest parser
("de-serialization" or "DOM tree-building" or Infoset) layer "before" 
the DOM API really gets involved--am I understanding you?  As such, 
the DOM itself never sees a relative URI reference for a namespace 
name, so you've defined the problem away for the DOM layer.

Assuming the DOM is built on the Infoset, this might work if the
Infoset spec is revised (as part of "introducing absolutization")
to do the absolutization at that level (which is, by the way, the
way the latest Infoset draft is written).  That basically moves 
the problem from the DOM domain to the Infoset domain.  This might
be a good way for the DOM work to continue (of course, it doesn't 
help the Infoset work).

paul

Received on Thursday, 8 June 2000 12:32:50 UTC