W3C home > Mailing lists > Public > public-i18n-its@w3.org > April to June 2006

[Bug 3319] Namespace binding mechanism

From: <bugzilla@wiggum.w3.org>
Date: Wed, 28 Jun 2006 12:29:40 +0000
To: public-i18n-its@w3.org
Message-Id: <E1FvZAq-0003r9-7D@wiggum.w3.org>


sebastian.rahtz@oucs.ox.ac.uk changed:

           What    |Removed                     |Added
                 CC|                            |sebastian.rahtz@oucs.ox.ac.u
                   |                            |k

------- Comment #2 from sebastian.rahtz@oucs.ox.ac.uk  2006-06-28 12:29 -------
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="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?

Received on Wednesday, 28 June 2006 12:29:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:04:10 UTC