RE: comments on behalf of the i18n-core-wg

>file:///c:/users/felix/reviews/qt-suite-20050404/qt-review-overview.htm
l
<file:///c:\users\felix\reviews\qt-suite-20050404\qt-review-overview.htm
l> 

 

Please correct this URI since it refers to something on your machine.

 

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Nepean, Ontario K2E 6A3
Tel: (613) 225-5445 Fax: (425) 936-7329
mailto:pcotton@microsoft.com

 

________________________________

From: w3c-xml-query-wg-request@w3.org
[mailto:w3c-xml-query-wg-request@w3.org] On Behalf Of Felix Sasaki
Sent: May 17, 2005 12:52 PM
To: w3c-xml-query-wg@w3.org; w3c-xsl-wg@w3.org
Cc: public-i18n-core@w3.org
Subject: 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
<file:///c:\users\felix\reviews\qt-suite-20050404\qt-review-overview.htm
l> 
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-prefix
es> , 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.