[
Lists Home |
Date Index |
Thread Index
]
> Just to be clear: XOM does not attempt to resolve the
> namespace URI. It
> simply rejects namespace URIs that are not syntactically correct
> absolute URIs. The only place I've seen this to be an issue
> is in test
> suites, particularly the OASIS XSLT test suite.
Yes, test suites are probably the biggest problem area.
But I have always tended to follow the dictum that the length of a name
should be proportional to its scope, and where I have to invent namespaces
for local use, e.g. for user-written functions in a stylesheet, I tend to
use a short name, simply to emphasize the absence of global significance. I
fail to see why it's OK to call something "http://f"; when it's not OK to
call it "f": the latter is at least honest, and clearly indicates that the
name is a local one.
XSLT 1.0 explicitly states that the processor should allow any string as a
namespace name, and XSLT 2.0 retains this. During the draft stages of
Namespaces 1.1 I pressed the WG to state clearly what the rules were, and
the fact that the Namespaces spec does not say that an invalid URI/IRI (let
alone a valid relative URI) is a WF error was clearly a deliberate decision.
If they had banned other names in the base spec we would have banned them in
XSLT also.
I think that higher-level specs and tools should not impose rules that
aren't in the base spec - it feels like nannying. But the problem here does
lie in the base spec: describing the namespace name throughout the spec as a
URI/IRI, and then saying in the conformance rules that it can be any string
you like, is just asking for trouble.
Michael Kay
http://www.saxonica.com/
|
