xml-xalan-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 5638] - namespace in stylesheet causes TransformerConfigurationException
Date Mon, 14 Jan 2002 16:23:20 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5638>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5638

namespace in stylesheet causes TransformerConfigurationException





------- Additional Comments From keshlam@us.ibm.com  2002-01-14 08:23 -------
Namespace Names are _not_ just strings, unfortunately.

The XML Namespaces spec explicitly says that Namespace Name _MUST_ be a URI 
reference. (First sentence of section 2, immediately following the BNF: 
"[Definition:] The attribute's value, a URI reference, is the namespace name 
identifying the namespace.") Anything else is syntactically incorrect.

The Great Namespace Debacle, which was a massive argument within the W3C about 
whether "URI reference" had really been intended to deal relative references and 
URIs in other than minimal form, and what possible consistant interpretation or 
practical use those could possibly have if so, deadlocked in a three-way 
undecidable. The result was a W3C announcement that relative URIs as Namespace 
Names are officially Unsupported, until and unless someone put forward a 
proposal that all three camps could tolerate. This means that no application is 
required to tolerate them, and no two applications should be expected to respond 
to them the same way. If you care in the least about portability, avoid relative 
Namespace Names like the plague until this has been settled.

Last I heard, responsibility for resolving that design issue had been given to 
the Semantic Web team, since TimBL felt that it was strongly related to those 
concerns and a recommendation was likely to fall out of that working group's 
efforts. I have no idea what the status of the Semantic Web effort currently is, 
but I don't expect that to be a quick effort.


Meanwhile: The given string, if it is a syntactically valid URI at all (which I 
don't believe it is), would clearly be a relative URI since it does not start 
with a "scheme". It's thus firmly within this Unsupported space, and I don't 
believe we should invest any effort in attempting to support it. No matter how 
we attempt to interpret it, we have a two-thirds chance that our code will be 
wrong. 

I advise that we wait for the W3C to decide what, if anything, it means -- with 
the understanding that they may, in fact, decide to simply make the status quo 
the final answer and permanantly change the namespace spec to forbid relative 
syntax, in which case rejecting this file would definitely be the Right Thing to 
do. 

(Having been an active participant in the Debacle, I actually think that's a 
high-probablity outcome. All the alternatives open _very_ ugly cans of worms; it 
is possible to come up with rules for how to cook those worms, but I find it 
unlikely that anyone will want to eat worms in the first place.)

Are we required to check the URI syntax? No; we probably should but that's a 
quality-of-implementation issue. Are we required to accept bad URI syntax? 
Definitely not.


Sorry, but the answer really is to fix the source file.


Only reason I haven't closed this is because we ought to check that exception to 
see if its text is diagnostically useful, and if not we should improve it.

Mime
View raw message