comments on behalf of the i18n-core-wg

Dear members of the xml-query-wg and the xsl-wg,

We, the i18n-core-wg, have reached consensus on our last telecon on 
several of the comments we recently submitted to Bugzilla. Following a 
proposal from Liam Quin, we have assembled them in this mail. You will 
find other comments in
file:///c:/users/felix/reviews/qt-suite-20050404/qt-review-overview.html
and in the bugzilla system. Please check whether these are old comments 
for which you already had a resolution. If this is the case, then just 
give us a short notice on the resolution and state the comments as 
RESOLVED. We will continue the discussion of the comments on the next 
i18n-core-wg telecon which is 25 May.

Best regards, Felix Sasaki.

-----------------------------------------------------------------------------------------------------------
Below you will find the comments on XPath which we have consensus on in 
our wg.

[1] General comment on references to URIs. Throughout this and other 
specs, please reference IRIs (RFC 3987 
<http://www.ietf.org/rfc/rfc3987.txt>) instead of URIs. You often refer 
to the XML Schema data type xs:anyURI, e.g. "The URI value is whitespace 
normalized according to the rules for the xs:anyURI type in [XML 
Schema]." (sec. 2.1.1). Referring to IRI directly in your specification 
would make things clearer. You could add s.t. like what the Voice 
Browser wg added to Vxml 2.1: "The xsd:anyURI type and thus URI 
references in VoiceXML documents may contain a wide array of 
international characters. Implementers should reference RFC 3987 and the 
Character Model for the World Wide Web 1.0: Resource Identifiers in 
order to provide appropriate support for these characters in VoiceXML 
documents and when processing values of this type or mapping them to URIs. "

[2] Sec. 2.1.2 <http://www.w3.org/TR/xpath20/#eval_context>, Definition 
of an "Implicit time zone": This should be removed. Using implicit 
conversions between timezoned and non-timezoned dates and times is way 
too prone to all kinds of subtle and not so subtle bugs.

[3] Sec. 2.2.3.1 <http://www.w3.org/TR/xpath20/#id-static-analysis> "The 
operation tree is then normalized ...": Please give a unique term to the 
different form of normalizations you are addressing, e.g. "operation 
tree normaliztation". There are many different normalizations in this 
series of specifications, like operation tree normalization in this 
section, white space normalization (sec. 3.10.2, 4c), Character 
normalization (Charmod, NFC etc.), normalization as described in the 
formal semantics document, sec. 3.2.1, point 3, and sequence 
normalization as described in the serialization specification, sec. 2. 
These should be very clearly distinguished and labeled. A section which 
summarizes the various kinds of normalization would be helpful.

[4] Sec. 3.5.1 <http://www.w3.org/TR/xpath20/#id-value-comparisons>: The 
value comparison relies on atomization of the values; if these are 
nodes, the atomized value is returned as a typed value. You should make 
clear that this is quite different from the comparison of string values. 
This difference might be important for some i18n applications. Consider 
the following example:

<myEl1>bla<myEl2>&#x160;</myEl2></myEl1>

if there is a schema which declares the type of myEl2 as empty, &#x160; 
would not be part of the PSVI and the result of

$myDoc/myEl1 eq "bla"

would be true, otherwise it would be false.

-----------------------------------------------------------------------------------------------------------
Below you will find the comments on XPath Functions & Operators which we 
have consensus on in our wg.

[1] Sec. 10.1 
<http://www.w3.org/TR/2005/WD-xpath-functions-20050404/#date-time-values> 
on Date/time datatype values: You write "For comparing or subtracting 
xs:dateTime values, this local value is translated or normalized to UTC 
(timezone Z)." This should be read as "Before comparing... this local 
value should (must?) be normalized to UTC." Please also change "This 
value is referred to as the local or localized value" to "This value is 
referred to as the local value", because "localized" as a specific 
notion in localization.

[2] Sec. 1.1 
<http://www.w3.org/TR/2005/WD-xpath-functions-20050404/#namespace-prefixes>, 
and in general: Please refer to IRI instead of URI, e.g. "Namespace URI" 
-> "namespace IRI", "The URIs of the namespaces" -> "The IRIs of the 
namespaces". We don't ask you to change your data type, because we know 
that you are relying on xs:anyURI, but please add a reference to IRI in 
a note.

[3] Sec. 3 
<http://www.w3.org/TR/2005/WD-xpath-functions-20050404/#func-error> on 
the error function: The indication of the language of the description 
may be useful. Having additional information on the language may be 
important for rendering. We also need a way to provide messages in 
different languages.

[4] Sec. 6.4.4 
<http://www.w3.org/TR/2005/WD-xpath-functions-20050404/#func-round> on 
rounding: in addition to the current rounding, please add a facility for 
user defined roundings. See 
http://www.xencraft.com/resources/multi-currency.html#rounding) for the 
need of this facility.