Re: Mechanism, not policy [was: Attribute uniqueness...]

   > If we accept that premise, then the assertion that a URI Reference really
   > ought to be a reference to a family of URIs (with the specific one selected
   > at the time that the reference is examined, in context) makes a bit more
   > sense. It explains the fact that ..\light lights a bulb in one case and a
   > fuse in another as being an _intentional_ result of the decision to use a
   > context-dependent reference in the first place. The answer "if it hurts
   > when you do that, don't do that" really is consistant with this model.
   > 
   > Of course, making sense, being desirable, and being wise may be three very
   > different things.

   Quite. To say "using a relative URI reference is almost always stupid
   and risky, so don't do that" is a fine policy for practitioners
   to adopt, if they so choose.

   To go further and say "... so let's prohibit it from the syntax"
   is to gum up the mechanism with exceptions based on policy.


You appear to be agreeing (as I do) with Joe Kesselman's quoted
statement that the literal interpretation is workable and gives the
expected behaviour on relative URI. If we do all agree on that
then it is true that there is no need to consider the forbid option,
and all that needs doing is fixing xpath spec to match xpath
implementations and the namespace spec. But somehow I suspect life
won't be so simple.

If the namespace name is being used for namespace processing then
basically neither you nor the processor ever needs to be aware
whether or not the name is a relative URI (what's the point of
checking for a : if you are going to do the same thing with the string
whatever is there?) So I don't see any "risk" in that (except for
people who misread the namespace spec and mistakenly expect to
be able to locate anything at the namespace name URI).

If some process does decide to dereference the namespace name
the expected behaviour, given a relative URI, must be that what you get
depends on the current base. But any such dereferencing happens
after any namespace processing and should not be an issue for the
namespace spec.


David

Received on Wednesday, 7 June 2000 13:57:38 UTC