Re: The "deprecate/fixed-base" option

> I would like there to be more consideration of the option I will call
> "deprecate/fixed-base".  This has two parts:
> ...
> "./foo" and "foo" namespaces will technically compare differently.

there are two variants of that (I could live with either, but I wasn't
sure which you meant)

Variant 1)
namespace processing takes the literal approach, and if some later
processing requires to use a URI (eg to retrieve a resource) then
the supplied base is taken.

variant 2)
the namespace name is always an absolute URI (eg sax2, xpath, etc
should report it as such) a relative URI in the attribute value will
be made absolute with respect to the stated base.

Personally I'd prefer variant 1, but I could live with variant 2.

Probably you'd need to say (for the record) whether relative paths
with too many ../ were an error or whether any of the fallback options
which I think are mentioned in the RFC are taken. (having a fixed
base with a relatively deep path section would avoid this problem in
practice)


David

me> This fixed base alternative might be much less disruptive than the
me> forbid option. (I am still not sure about it, but I think that it
me> could be seriously considered.)