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

Dan Connolly wrote:
 
> 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.

A namespace processor has to compare namespace names for identity to
enforce the rule on attribute uniqueness.  Does a namespace processor
compare names literally (without regard for base) on this proposal?

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

I don't buy that.  I don't think "namespace URI" is any more suggestive
of the absolute form than "namespace name".

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

That seems like a non-solution to me and a waste of all the effort that
has been put into this discussion.

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

The key issue is what's in the XPath data model.  That determines how
names are matched for identity.  If you're implying that XPath
determines name identity using absolutized names, then you're proposing
that the XPath Rec and the Namespaces Rec simultaneously use
inconsistent methods for determining name identity for a particular
namespace name.  I find that completely unacceptable.

Either:

a) the data model should say it's undefined consistently with what you
are proposing for the infoset and the DOM; or

b) the data model should contain the unabsolutized name, thus ensuring
that the XPath Rec compares names consistently with Namespaces Rec

Note that XSLT tracks the base URI and automatically absolutizes when
you use a relative URI to access a resource with the document()
function.  The only case where this breaks down is if an external entity
inherits namespace declarations from the referencing entity and it has a
different base URI.  One could add complexity to make this case work
too, but it doesn't seem worthwhile to me.

Things will work quite nicely if namespace-uri() returns the
unabsolutized URI reference, and this also matches the behaviour of the
overwhelming majority of deployed XSLT implementations.

>         [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'm not sympathetic.  Why add complexity just to deal with a deprecated
case?

>         I'd certainly like to see uri-expand(base, uriRef)
>         and uri-relative-with-respect-to(here, there)
>         utility functions added to XPath/XSLT

document() has this functionality built in, but it would be sometimes be
useful to have it available separately as well.

James

Received on Saturday, 24 June 2000 01:05:12 UTC