3319
2006-06-07 05:55
Namespace binding mechanism
2007-02-16 05:39:40
1
1
1
Unclassified
ITS
ITS tagset
CR
PC
Windows XP
RESOLVED
FIXED
changeDeclined
P2
normal
DuringCR
1
fsasaki@w3.org
sebastian.rahtz@oucs.ox.ac.uk
cmsmcq@w3.org
sebastian.rahtz@oucs.ox.ac.uk
werner.donne@re.be
fsasaki@w3.org
fsasaki@w3.org
2006-06-07 05:55:06
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.
fsasaki@w3.org
2006-06-20 05:14:55
Added Werner and Michael to the CC list, to keep them in the loop.
sebastian.rahtz@oucs.ox.ac.uk
2006-06-28 12:29:39
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
werner.donne@re.be
2006-06-28 12:52:26
Sebastian,
I can accept the explanation. Thank you.
Werner.
sebastian.rahtz@oucs.ox.ac.uk
2006-06-28 13:05:41
Please note that my examples in the last comment
were not using the current naming :-{
However, that didnt affect the point, I hope.
sebastian.rahtz@oucs.ox.ac.uk
2006-07-12 14:40:00
Michael,
I am proposing to close this bug on 21st July unless
we hear from you to the contrary by then.
Hope thats OK
fsasaki@w3.org
2006-07-24 12:37:07
Wait: answer sent, wait respone.
ysavourel@translate.com
2006-09-06 23:10:52
Closed. No answer after 2 weeks.
fsasaki@w3.org
2006-09-28 06:06:24
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.
cmsmcq@w3.org
2006-10-30 01:41:05
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.)
sebastian.rahtz@oucs.ox.ac.uk
2006-12-20 15:39:12
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.
fsasaki@w3.org
2007-02-16 05:38:10
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.
4096
2006-12-19 04:10
Inheritance and overriding needs to be made clearer
2007-02-15 14:33:24
1
1
1
Unclassified
ITS
ITS tagset
CR
PC
Windows XP
RESOLVED
FIXED
P2
normal
---
4327
1
fsasaki@w3.org
fsasaki@w3.org
fsasaki@w3.org
2006-12-19 04:10:49
See thread at http://lists.w3.org/Archives/Public/public-i18n-its/2006OctDec/0037.html .
Current summary: http://www.w3.org/TR/2006/CR-its-20061102/#selection-precedence is unclear about the position of linked rules in the precedence order. The difference between linked rules and external rules (if there is one) is unclear. There is the proposal of giving local, *inherited* information precedence over global rules, which may be dropped.
fsasaki@w3.org
2007-02-02 22:10:44
Resolved by the following reformulation of the list in sec. 5.4, see action item http://www.w3.org/2006/12/13-i18nits-minutes.html#action10 :
1.Implicit local selection in documents (ITS local attributes on a specific element)
2. Global selections in documents (using a rules element) Inside each rules element the precedence order is:
1. Any rules inside the rules element
2. Any rules linked via the XLink href attribute
Note: If identical selections are defined in different rules elements within one document, the selection defined by the last takes precedence.
Note: ITS doesn't define precedence related to rules defined or linked based on non-ITS mechanisms (such as processing instructions for linking rules).
3. Selections via defaults for data categories, see Section 6.1: Position, Defaults, Inheritance and Overriding of Data Categories
4098
2006-12-19 04:15
Need to make more explicit: what is possible with XSLT patterns realizing ITS selectors?
2007-02-02 05:34:43
1
1
1
Unclassified
ITS
ITS tagset
CR
PC
Windows XP
RESOLVED
FIXED
P2
normal
---
1
fsasaki@w3.org
fsasaki@w3.org
fsasaki@w3.org
2006-12-19 04:15:07
See thread at http://lists.w3.org/Archives/Public/public-i18n-its/2006OctDec/0043.html .
Summary: XSLT patterns like in e.g. <xsl:template match="pattern">... allow only for a subset of XPath. The ITS selector attributes allow for full XPath expressivity. We need to give adivce for people who use XSLT what XPath subset is safe to be used.
fsasaki@w3.org
2007-02-02 05:34:43
Closed with text proposal at http://lists.w3.org/Archives/Public/public-i18n-its/2006OctDec/0087.html .
4099
2006-12-19 04:21
Format for implementation output needs to be clear
2007-02-15 14:40:24
1
1
1
Unclassified
ITS
ITS tagset
CR
PC
Windows XP
RESOLVED
FIXED
P2
normal
---
4317
1
fsasaki@w3.org
fsasaki@w3.org
fsasaki@w3.org
2006-12-19 04:21:37
See threads:
http://lists.w3.org/Archives/Public/public-i18n-its/2006OctDec/0058.html
Summary: let's have output markup not in the ITS namespace, but in some other namespace
fsasaki@w3.org
2007-01-10 15:43:54
Closed at http://www.w3.org/2007/01/10-i18nits-irc#T15-42-57 .
fsasaki@w3.org
2007-02-15 14:04:15
Related Action Item:
http://www.w3.org/2007/01/10-i18nits-minutes.html#action07
Proposal and Thread:
http://lists.w3.org/Archives/Public/public-i18n-its/2007JanMar/0014.html
fsasaki@w3.org
2007-02-15 14:40:24
Format is described in implementation report at http://www.w3.org/International/its/itstagset/ImpReport#testsuite .
4152
2007-01-06 03:58
Need to make explicit that ITS attributes at its:span are not namespace qualified
2007-02-15 14:28:15
1
1
1
Unclassified
ITS
ITS tagset
CR
PC
Windows XP
RESOLVED
FIXED
P2
normal
---
4325
1
fsasaki@w3.org
fsasaki@w3.org
fsasaki@w3.org
2007-01-06 03:58:17
It needs to be made explicit that attributes at its:span are not namespace qualified. E.g., we have
<its:span translate="no"> ...
but not
<its:span its:translate="no"> ...
Targets: The ODD definition which currently describes these attributes as *namespace qualified*, and http://www.w3.org/TR/2006/CR-its-20061102/#selection-local .
fsasaki@w3.org
2007-01-31 16:41:16
Closed with proposal at http://www.w3.org/2007/01/31-i18nits-minutes.html#action12 and the change of the ODD schema (copying the attributes in a namespace qualified and non namespace qualified version).
fsasaki@w3.org
2007-02-13 01:07:11
See latest update at http://lists.w3.org/Archives/Public/public-i18n-its/2007JanMar/0091.html
4289
2007-01-31 15:19
Various mainly editorial changes
2007-02-15 14:37:25
1
1
1
Unclassified
ITS
ITS tagset
CR
PC
Windows XP
RESOLVED
FIXED
P2
normal
---
4323
4326
1
fsasaki@w3.org
fsasaki@w3.org
fsasaki@w3.org
2007-01-31 15:19:46
See mail at http://lists.w3.org/Archives/Public/public-i18n-its/2007JanMar/0052.html . Resolution: closed with edits described at http://www.w3.org/2007/01/31-i18nits-irc#T15-18-15 .
fsasaki@w3.org
2007-02-02 23:16:11
Additional change to proposal described at http://lists.w3.org/Archives/Member/member-i18n-its/2007JanMar/0071.html .
4290
2007-01-31 15:43
Create appendix about NVDL
2007-02-15 14:18:42
1
1
1
Unclassified
ITS
ITS tagset
CR
PC
Windows XP
RESOLVED
FIXED
P2
normal
---
4324
1
fsasaki@w3.org
fsasaki@w3.org
fsasaki@w3.org
2007-01-31 15:43:35
See proposal at http://lists.w3.org/Archives/Member/member-i18n-its/2007JanMar/att-0061/nvdl.xml.
Resolution: proposal accepted at http://www.w3.org/2007/01/31-i18nits-irc#T15-42-31
4291
2007-01-31 15:49
Having the version attribute at its:rules in no namespace
2007-02-15 14:31:52
1
1
1
Unclassified
ITS
ITS tagset
CR
PC
Windows XP
RESOLVED
FIXED
P2
normal
---
4296
1
fsasaki@w3.org
fsasaki@w3.org
fsasaki@w3.org
2007-01-31 15:49:30
See proposal at http://lists.w3.org/Archives/Public/public-i18n-its/2007JanMar/0044.html .
Resolution: Proposal accepted at http://www.w3.org/2007/01/31-i18nits-irc#T15-47-59
fsasaki@w3.org
2007-01-31 16:30:16
Editors AIs are (also)
http://www.w3.org/2007/01/31-i18nits-minutes.html#action05
http://www.w3.org/2007/01/31-i18nits-minutes.html#action06
http://www.w3.org/2007/01/31-i18nits-minutes.html#action06b
fsasaki@w3.org
2007-02-13 01:04:12
See latest update at http://lists.w3.org/Archives/Public/public-i18n-its/2007JanMar/0090.html .
fsasaki@w3.org
2007-02-13 01:07:44
Last update was wrong, should have been for issue http://www.w3.org/Bugs/Public/show_bug.cgi?id=4152 .
fsasaki@w3.org
2007-02-15 14:31:52
Issue closed with changes described at http://lists.w3.org/Archives/Public/public-i18n-its/2007JanMar/0090.html .
4293
2007-02-02 01:40
Editorial fix in sec. 6.6.2
2007-02-13 08:46:09
1
1
1
Unclassified
ITS
ITS tagset
CR
PC
Windows XP
RESOLVED
FIXED
P2
normal
---
1
fsasaki@w3.org
fsasaki@w3.org
fsasaki@w3.org
2007-02-02 01:40:53
"An optional rpPointer attribute that contains a relative XPath expression pointing to a node that corresponds to the ruby parenthesis."
This sentence (bullet point) appears twice in sec. 6.6.2, one needs to be deleted.
christian.lieske@sap.com
2007-02-13 08:46:09
Felix made the change in version 1.126
4294
2007-02-02 05:28
Add xlink:type to <its:rules> element
2007-02-02 05:28:26
1
1
1
Unclassified
ITS
ITS tagset
CR
PC
Windows XP
RESOLVED
FIXED
P2
normal
---
1
fsasaki@w3.org
fsasaki@w3.org
fsasaki@w3.org
2007-02-02 05:28:16
See comment at http://lists.w3.org/Archives/Public/public-i18n-its/2006OctDec/0073.html and discussion at http://www.w3.org/2006/12/20-i18nits-minutes#item04 . Resolution: WG agrees with the comment and adds the xlink:type attribute to the <its:rules> element.
4295
2007-02-02 05:40
Change of XPath expressions in schematron example
2007-02-02 05:40:17
1
1
1
Unclassified
ITS
ITS tagset
CR
PC
Windows XP
RESOLVED
FIXED
P2
normal
---
1
fsasaki@w3.org
fsasaki@w3.org
fsasaki@w3.org
2007-02-02 05:40:06
See comment on schematron example at http://lists.w3.org/Archives/Public/public-i18n-its/2006OctDec/0073.html . Resolution: Closed with the editors action item at http://www.w3.org/2006/12/20-i18nits-minutes.html#action14 .
4322
2007-02-13 15:17
Editors to go to the draft and check that there are no "CSS style elements" or the like
2007-02-13 16:00:22
1
1
1
Unclassified
ITS
ITS tagset
CR
PC
Windows XP
RESOLVED
FIXED
P2
normal
---
1
christian.lieske@sap.com
fsasaki@w3.org
christian.lieske@sap.com
2007-02-13 15:17:44
See http://www.w3.org/2007/01/24-i18nits-minutes.html#action07
christian.lieske@sap.com
2007-02-13 16:00:22
Addressed in spec. version 1.128