This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 3319 - Namespace binding mechanism
Summary: Namespace binding mechanism
Alias: None
Product: ITS
Classification: Unclassified
Component: ITS tagset (show other bugs)
Version: CR
Hardware: PC Windows XP
: P2 normal
Target Milestone: DuringCR
Assignee: Sebastian Rahtz
QA Contact: Felix Sasaki
Depends on:
Reported: 2006-06-07 05:55 UTC by Felix Sasaki
Modified: 2007-02-16 05:42 UTC (History)
3 users (show)

See Also:


Description Felix Sasaki 2006-06-07 05:55:06 UTC
See comment from Werner Donne at , and from Michael Sperberg-McQueen at .

Summary: They propose to give up the <ns> element, and use the "xmlns" attribute instead.
Comment 1 Felix Sasaki 2006-06-20 05:14:55 UTC
Added Werner and Michael to the CC list, to keep them in the loop.
Comment 2 Sebastian Rahtz 2006-06-28 12:29:39 UTC
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"

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:documentRule its:translate="yes"

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=""/>

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?

Comment 3 Werner Donn 2006-06-28 12:52:26 UTC

I can accept the explanation. Thank you.

Comment 4 Sebastian Rahtz 2006-06-28 13:05:41 UTC
Please note that my examples in the last comment
were not using the current naming :-{

However, that didnt affect the point, I hope.
Comment 5 Sebastian Rahtz 2006-07-12 14:40:00 UTC

I am proposing to close this bug on 21st July unless
we hear from you to the contrary by then.

Hope thats OK

Comment 6 Felix Sasaki 2006-07-24 12:37:07 UTC
Wait: answer sent, wait respone.
Comment 7 Yves Savourel 2006-09-06 23:10:52 UTC
Closed. No answer after 2 weeks.
Comment 8 Felix Sasaki 2006-09-28 06:06:24 UTC
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.
Comment 9 C. M. Sperberg-McQueen 2006-10-30 01:41:05 UTC
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

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.)

Comment 10 Sebastian Rahtz 2006-12-20 15:39:12 UTC
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.
Comment 11 Felix Sasaki 2007-02-16 05:38:10 UTC
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.