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

keshlam@us.ibm.com wrote:
[...]
> 
> Before we jump on the Deprecate/Undefined bandwagon, I'd strongly encourage
> everyone to do a anity check of what its implications would be for other
> specs... both immediately and with an eye toward possible reconsideration
> of absolutize in the XML 2.0 timeframe. We need both to say that the
> behavior of relative namespace references is currently undefined _and_ to
> make sure that if/when a definitition arrives the impact on the spec and
> its users will be acceptable.

Yes, let's...

> I need to look at it again, but I think the DOM could get away with saying
> something like:

I am pretty much resigned to the fact that this is the best we can do,
in anything less than many months:

> "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."
> 
> (If that's correct, the DOM Level 2 CR would not have to be changed
> significantly to support this proposal; we'd just want to include some
> version of the above paragraph in our discussion of how we handle
> namespaces.)
> ______________________________________
> Joe Kesselman  / IBM Research


To elaborate a bit:

So regarding a doc at http://example.com/dir1/dir2/
        <aDoc xmlns="../foo"/>

Q: does it conform to XML 1.0?
A: of course; noone has suggested otherwise.
        It's well-formed.

Q: does it conform to the namespaces spec?
A: indeed, it does.
	But if you look at the errata page, you'll
	notice a big warning that you're asking
	for trouble by using relative URI references
	in namespace declarations.

Q: OK, then, what's the namespace name of the root element?
A: ../foo , per the namespaces spec as written.

	But be careful about calling it anything else,
	like "namespace URI" -- that terminology suggests
	that you're talking about the absolute form
	of ../foo w.r.t. the relevant base.

Q: In the infoset, what's the value of the in-scope-namespaces property
        of the root element?

A: unspecified; out of scope for this version of the infoset spec

	The infoset spec not only doesn't cover documents
	that are well-formed but not namespace-spec-conformant,
	this version doesn't cover documents that
	are namespace-spec-conformant but use relative URI
	references in namespace declarations.

(as Paul G put it:
2.  say that a document containing an nsattrib whose value is a
    relative URI has no defined infoset.)


Q: what does the DOM spec return for the namespaceURI attribute?

A: unspecified;
	(see elaboration by Joe K above)

Q: what's the value of the XPath namespace-uri() function
        with <aDoc> as the current node??

A: http://example.com/dir1/foo per the XPath and URI specs,
        but beware: we've seen implementations that don't
        give that answer.

	[I'm sympathetic to the suggestion
	to deprecate the namespace-uri() function
	in favor of separate raw-namespace-decl-attr-val()
	and absolute-form-of-namespace-decl-attr-val() functions;
	I'd certainly like to see uri-expand(base, uriRef)
	and uri-relative-with-respect-to(here, there)
	utility functions added to XPath/XSLT; I intend
	to code them up as extension functions, in the mean time. ]

This is something of a stop-gap solution for DOM2 and infoset,
but it allows W3C as a whole to get moving again. I'd like
to continue some of the architectural/philosophical discussions,
but asynchronous to the critical path of Infoset and DOM2.


-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Friday, 23 June 2000 00:43:27 UTC