Re: Personal view

> (unless I really seriously misunderstood either REC-xml-names or the 
>  absolutize option,

No that is, as you say, one of the main problems with this option.


>  The simple string comparison has the advantage of simplicity,
> and should be slightly less costly (in time/memory requirements)
> but denies the fact that namespace name are URI references 

It means that they are not URI, but it doesn't really deny that they
are URI references. URI references (as for example used in href
attributes) are also compared as strings until they are combined with
a base URI using the algorithm in the rfc.

However

> (and then possible anchors for associated namespace related metadata).

that is the valid concern with relative URI references as
namespace names.


> My personal opinion is still that relative URI in namespaces should
> be deprecated,

Do you mean "forbid" ie raise an error, or deprecate, which is allow,
but warn against? If deprecate then you have to say what to do, either
"literal" or "fixed base" options would avoid the problem you
mentioned above with the "make absolute" option. "fixed base"
would also provide the absolute URI required for rdf and similar
operations on namespace names.

>  So that "http://www.example.org/./a" is still a valid namespace name,
> but be clearly flagged as "bad practice".

While I agree that this is probably bad practice I doubt whether
anyone has ever done this, (unlike the case for relative URI as
namespace names, which are not that uncommon)
If we are going to give such advice I would go further than
recommending that ./ and ../ segments are bad practice. I think
everyone would agree that it is probably a bad idea (but strictly
conforming) to willfully specify two namespace names that would
have the same functional effect as URI, so apart from /./ you could
warn against using two namespace names that differ just by case, or using
two different DNS names that resolve to the same server etc etc etc,
whether this should be in the namepsace rec itself or in some advisory
note isn't so clear

> XPath-1.0 looks good too,
xpath currently recommends the absolute option. If by deprecate you
mean "forbid" then arguably xpath is Ok as relative URI won't occur
but in practice xpath 1.0 will need to be updated to confirm whatever
decision taken.

David

Received on Saturday, 17 June 2000 19:23:41 UTC