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

At 11:32 PM -0500 6/22/00, Dan Connolly wrote:

I like almost all of what Dan proposes below, and I'd like to repeat 
it in full, as I pick the few small nits that I have. This is a clear 
proposal that makes good sense to me.

>
>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.)

I'm not 100% sure that this is a good idea. My objection is based on 
a separate set of issues:

  1. Xlink should work for any well-formed XML document.
  2. XLink is defined on the information set of an XML document.
  3. Therefore, every well-formed XML document should have an information set.

I'd like to see a scenario where the information set of a document 
that has defective namespace declarations, or relative URIs in them, 
would instead have an information set _minus_ all namespace 
properties, just as it would have had if there were no namespace 
declarations.

Otherwise there would be no way for an Xpointer to select an XML 
element in a "namespace-defective document" because that document 
would not have an infoset.

Alternatively, if it's allowed to ask for the infoset of an XML 
document "explicitly ignoring" any apparent namespace declarations, 
then a fallback policy would be possible.

This is really an information set issue, that touches on the 
namespace issues, but it does seem closely enough related that it's 
worth thinking about.

>
>Q: what does the DOM spec return for the namespaceURI attribute?
>
>A: unspecified;
>	(see elaboration by Joe K above)

I pasted it in below

>  > "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."

I don't like undefined. I'd rather define it to be any random thing. 
But perhaps rigidly defined areas of doubt and uncertainty are the 
best that we can manage.

>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. ]

I think that this is right, especially your bracketed sympathy, which 
seems essential to me, as a way to remove the ambiguity, soonest.

The split of functions between literal and resolved actually seems 
like it's almost universally needed where URI references are parsed, 
and some applications (like editors) need a literal view of the URI 
reference, even where it's generally unimportant for processing.

>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.

Given the need for literal and absolutized access to URIs in several 
contexts, it may not even be that much of a stopgap.

I'd like to see this, and pass on the philosophy for the time being. 
I think the philosophy will be worthless unless, and until, it's 
based on developing at least one standard MIME-type for entities to 
be returned on retrieval of a namespace URI.

   -- David
-- 
_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
http://cs-people.bu.edu//dgd/             \  Chief Technical Officer
     Graduate Student no more!              \  Dynamic Diagrams
--------------------------------------------\  http://www.dynamicDiagrams.com/
                                              \__________________________

Received on Friday, 23 June 2000 13:46:05 UTC