This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
See comment from Werner Donne at http://lists.w3.org/Archives/Member/member-i18n-its/2006AprJun/0107.html , and from Michael Sperberg-McQueen at http://lists.w3.org/Archives/Member/member-i18n-its/2006AprJun/0097.html . Summary: They propose to give up the <ns> element, and use the "xmlns" attribute instead.
Added Werner and Michael to the CC list, to keep them in the loop.
I'd like to clear up the issue around bug 3319 report for the ITS proposal. This concerns the use of the <ns> element to declare a namespace prefix which will subsequently be used in XPath expressions. Werner's comment is: >> 2) The "ns" element is there to declare namespace bindings in the >> scope of a rules element. Why can't the regular namespace >> declaration be used? Its scope can also be limited to the rules >> elements and the prefix bindings of the document itself could >> be used to interpret the XPath expressions in the select attributes. >> This is often likely to be what is desired, because the XPath >> expressions address parts of the document itself. The situation that <ns> is designed to be used is when we have a rule which talks about namespaced elements. Thus: <its:documentRule its:translate="yes" its:selector="//tei:body"/> In this context, we need to talk about <body> in the TEI namespace. The prefix "tei:" is here not being parsed, so there is no corresponding declaration. If we added one: <its:documentRules xmlns:tei="whatever/foo/bar" xmlns:its="http://www.w3.org/2005/11/its"> <its:documentRule its:translate="yes" its:selector="//tei:body"/> then a processor which parses the XML has no formal way to relate the first "tei" to the second "tei", since the namespace declaration is an instruction to the XML parser. It may legally write the document without the declaration (and indeed will probably do so if there are no elements in the namespace). However, if we add <its:ns its:prefix="tei" its:uri="http://www.tei-c.org/ns/1.0"/> then the relationship is made explicit, and the XML parser cannot throw it away. Does this long-winded explain why we did it like this (copying the idea from Schematron)? Because, to summarize, the xmlns declaration may be changed or dropped by some XML application earlier in the processing chain, and lose the information about the prefix. Michael and Werner, would you be willing to accept this explanation, and close the bug? Sebastian
Sebastian, I can accept the explanation. Thank you. Werner.
Please note that my examples in the last comment were not using the current naming :-{ However, that didnt affect the point, I hope.
Michael, I am proposing to close this bug on 21st July unless we hear from you to the contrary by then. Hope thats OK
Wait: answer sent, wait respone.
Closed. No answer after 2 weeks.
Summary: The Working Group decided not to change the namespace binding mechanism, because we want ITS global rules to be independent of existing (and possibly changing) namespace declarations.
My apologies for my delinquency in not responding earlier to your email. I agree that tools of the sort described by Sebastian Rahtz exist. But if such tools are used in situations where content or attribute values may contain QNames, and the tool being used does not know how to figure out whether a particular binding is in use or not, then the use of the tools is wrong-headed and a mistake, just like the invocation of any tool that changes the infoset in situations where the change in question is wrong. xmlns:foo is NOT an instruction to the parser. It is a purely declarative statement about a binding between a prefix used in QNames and a namespace name. It does not instruct the parser to do anything in particular, any more than any other attribute. I think better solutions for this situation would be: use an expanded-name syntax for the expressions, and clarify that before use, the expressions must be translated into QName form using an appropriate binding (theoretically clean, but cumbersome and prone to misunderstanding -- I don't recommend this seriously). Or: add a health warning noting that when XPath expressions are being transmitted, it's dangerous to use tools of the sort described. If it's essential to know that a particular prefix is used in XPath expressions and not just in generic identifiers and attribute names, then by all means make a declaration that has that as its meaning (like the import facility in XML Schema, which acts as a signal that a particular foreign namespace may be referenced). But do NOT replicate the namespace mechanisms. That way lies madness. Again, my apologies for this dilatory reply. If it's too late, I will hardly be able to resent your replying in turn that it's too late to reconsider this. But I'm not able to say "it's OK with me," so if you're unable to reopen consideration of this topic, I ask that you record this as an unresolved issue and a formal objection. (Sorry about that.)
I have now worked out how to use the normal namespace decls in an efficient way in XSLT 1.0, so I believe the <ns> element can now be dropped. Pending final check from implementors.
The ineroperability testing during CR phase should that the namespace binding via "xmlns" attributes can handle all functionality the specification needs. Hence, the alternative namespace binding via the "ns" element (a "feature at risk") was dropped from the specification.