Felix Sasaki fsasaki@w3.org
These are so far personal comments, NOT on behalf of the I18N WG.
| ID | Location | Comment | Additional information | Accepted |
|---|---|---|---|---|
| 1 | General | General comment on references to URIs. Throughout this and other specs, please reference IRIs (RFC 3987) 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. " | See Bugzilla | - |
| 2 | Sec. 2.1.2, Definition of an "Implicit time zone" | This has to 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. | Based on Martin's review, comment [3]. See Bugzilla | - |
| 3 | Sec. 2.2.3.1 "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. | Based on Martin's review, comment [4]. See Bugzilla | - |
| 4 | Sec. 3.5.1 | 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>Š</myEl2></myEl1> if there is a schema which declares the type of myEl2 as empty, Š would not be part of the PSVI and the result of $myDoc/myEl1 eq "bla" would be true, otherwise it would be false. |
Based on Martin's review, comment [8]. See Bugzilla | - |
| 5 | References | The reference to ISO/IEC 10646 should be updated to the newest version, i.e. ISO/IEC 10646:2003. | Based on Martin's review, comment [10]. See Bugzilla | accepted |
Version: $Id: xpath-review.html,v 1.10 2005/05/25 03:18:24 fsasaki Exp $