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

> We already have documents which are XML-well-formed but not NS-well-formed
> (due to NS-mediated attribute clashes).

Also due the one : rule, no?

<a:b:c/>

fails to have an infoset,and does not work with xpath (thus xpointer
xlink etc), doesn't it?


>  I'm not
> convinced that forbidding relative syntax in the NS declaration is a
> signficant step beyond that point.

forbid is OK so long as it's clear it will stay forbidden (ie there isn't
an intention of introducing element names that depend on context
with a NS version 2 in a year's time)

But I think people underestimate how many documents this would break
(if the systems enforced it). I would remove all relative URI from
any namespace declarations on my files (I'll do that anyway, I think:-)
but it's really not difficult  to find examples of use of such
namespace names with a bit of websearching, and probably the majority
of XML files currently aren't directly viewable on the web as browser
support means server side transform to html is common, (or the files
are private anyway). So any estimate of the number of files broken by
forbid would just be a total guess.

If forbid really is the best option, I don't know of any good way of
reaching these people and asking them to change their documents. If
the tools don't change, then of course, in practice they won't change
their documents. Perhaps that's the price of progress, but perhaps no
one would be immensely surprised if I said that I would think that
literal+deprecate or fixed-base would be preferable to forbid, however
forbid is OK, and anything at all is preferable to "make absolute".


David

Received on Friday, 23 June 2000 15:18:55 UTC