RE: I18N last call comments on XQuery/XPath Fun/Op (first part) [21]

Comment [21] says...
[21] 3. ***Error function: How can error messages be localized?

Michael Kay replied "describing our thinking on this. A suggestion is
that errors should be denoted by a QName using an application-specific
namespace URI and a language-neutral local name. Implementations should
provide mechanisms allowing such a QName to be translated into an error
message appropriate to the user's locale." See
http://lists.w3.org/Archives/Member/w3c-query-operators/2003Jul/0037.htm
l.

The WGs decided on 9/18/2003 that this was an adequate response to your
concerns and decided to close the issue.  Thank you for your comment.

All the best, Ashok

> -----Original Message-----
> From: public-qt-comments-request@w3.org [mailto:public-qt-comments-
> request@w3.org] On Behalf Of Martin Duerst
> Sent: Monday, July 07, 2003 2:06 PM
> To: public-qt-comments@w3.org
> Cc: w3c-i18n-ig@w3.org
> Subject: I18N last call comments on XQuery/XPath Fun/Op (first part)
> 
> 
> Dear XML Query WG and XSL WG,
> 
> Below please find the I18N WGs comments on your last call document
> "XQuery 1.0 and XPath 2.0 Functions and Operators"
> (http://www.w3.org/TR/2003/WD-xpath-functions-20030502/).
> 
> Please note the following:
> - Please address all replies to these comments to the I18N IG mailing
>    list (w3c-i18n-ig@w3.org), not just to me.
> - All i18n-relevant comments are marked with ***. There are also
general
>    comments on the spec which we hope you will find useful.
> - We have not yet reviewed the other documents, such as XQuery 1.0
>    or XSLT 2.0, and so we might be unaware of i18n issues that appear
>    in these specs but may have to be traced back to functions and
> operators.
>    There are also cases where we have identified an i18n issue here,
>    but we are not sure exactly what the best solution will be, and
which
>    document it will have to be addressed in. Also, there are issues
that
>    have been raised in comments to you about a different document but
>    that apply to this document, too. Sometimes, this is mentioned
below,
>    but not always.
> - Our comments are numbered in square brackets [nn].
> 
> We look forward to further discussion with you to find the best
> solution on these issues.
> 
> 
> [1] Status of this document: The 'last call' information should be
>      close to the start, not the end, of this section.
> 
> [2] 1.1 implementation defined:
>      "Possibly differing between implementations, but specified by the
> implementor for each particular implementation."
>      better: "Possibly differing between implementations, but
specified
> and
> documented by the implementor for each particular implementation."
> 
> [3] 1.2: *** re. anyAtomicType/untypedAtomic, see data model comments
> 
> [4] 1.2: ur types -> urtypes
> 
> [5] 1.2: "Diagram courtesy Asir Vedamuthu, webMethods and Jim Melton,
> Oracle"
>      Without any disrespect to these two hard-working gentlemen, this
is
> the
>      first time we have seen such an in-place acknowledgement in a W3C
> spec,
>      it does not seem appropriate, in particular because the image is
> mostly
>      a copy from XML Schema. If necessary, an ack in the ack section
> should do.
> 
> [6] 1.2: ***yearMonthDuration and dayTimeDuration:
>      glad to see that you are fixing
>      a well-known XML Schema problem.
> 
> [7] 1.3.2: ***the motivation for untypedAtomic seems unclear. There
may be
> many
>      other cases where one wants to indicate that subtypes/derived
types
>      are not acceptable. If this is considered important, then there
> should
>      be a general solution. See also our other comments on this type.
> 
> [8] 1.4: ***Regarding associating Z with dates/times without timezone,
see
>     our comments on data model.
> 
> [9] 1.4: Please provide a pointer to the normative spec for the
mappings
>     (that there are not enough pointers, and it's often not clear what
>      is the normative specification of something, is a general issue
>      with the current set of specs)
> 
> [10] 1.6: This speaks about constructors. The issues list for the data
> model
>     says constructors are gone. This is confusing.
> 
> [11] 1.6: "For most functions there is a paragraph describing what the
> function does followed by semantic rules. These rules are meant to be
> followed in the order that they appear in this document."
>      This seems to imply that some details in an earlier (in the spec)
>      function definition can influence some details in a later
>      (in the spec) definition. Please clarify.
> 
> [12] 1.6: Qname is defined in XML namespaces, not XML 1.0.
> 
> [13] 1.6, end: It would be good to add a small explanation about
multiple
>     parameters and sequences as parameters. (and that this is or is
>     not working the same way as in Perl)
> 
> [14] 1.7: "Are in the XML Schema namespace": Please always give the
>     namespace URI in such cases.
> 
> [15] 1.7: "datatypes described in this document": Are there any? Where
are
>       the descriptions?
> 
> [16] 2.3: What is the difference between fn:string() and fn:string(as
> item?)?
>      If there is no item, then that's the same as the first variant,
or
> not?
> 
> [17] 2.3: *** here and elsewhere: anyURI is not exactly an URI!
> 
> [18] 2.4: Why does this function work on sequences, but others don't?
>       This is a general issue.
> 
> [19] 2.5: What about the case that the base URI is found in the node's
>     grandparent, or even higher up?
> 
> [20] 2.5: What is 'static context'?
> 
> [21] 3. ***Error function: How can error messages be localized?
> 
> [22] 4. .implementation defined. : These dots look strange.
> 
> [23] 4. Ordering implementation defined: This should be that the
ordering
> is
>     according to execution order, which may be implementation defined.
>     Anything less diminishes the value of the error mechanism
> considerably.
> 
> [24] 5.1: xs:TYP: shouldn't this be xs:TYPE?
> 
> [25] 5.1: ***The return type of anyURI as QName seems strange. 17.14
does
> not
>       seem to explain why this special constructor appears in 5.1.
> 
> [26] 5.2: Rules are defined in the same way: What rules exactly?
> 
> [27] 6.2: Subtype substitution and type promotion should be described
>     normatively in this spec.
> 
> [28] 6.2.6: (a/b)*b+(a mod b) -> (a idiv b) * b + (a mod b)
> 
> [29] 6.2.7: Why do we need unary plus? If there is a need for a 'noop'
>     function, it may be better to have a general one.
> 
> [30] 6.4: ***Rounding functions: We are not sure that floor, ceiling,
> round,
>      and 'round-half-to-even' cover the rounding conventions around
>      the world in a balanced way. We need to look into this in more
>      detail. (for some examples, please see
>      http://www.xencraft.com/resources/multi-currency.html#rounding).
>      Also, what is 'round-half-to-even' used for?
> 
> [31] 7.1: ***String types: It is very important to integrate
> anyType/anySimpleType
>     (and if kept, untypedAtomic) and text nodes here.
> 
> 
> [32] *** 7.1: "except for the range #xD800 to #xDFFF inclusive, which
is
> the range reserved for surrogate pairs"
>      "surrogate pairs" -> "surrogates"
> 
> [33] *** 7.1: What is the difference between 'code point' and
'character'?
>      There are a few code points that are not characters (e.g. #xFFFE
and
>      #xFFFF), but that can hardly be the point of having two
definitions.
> 
> [34] *** 7.2.1 and 7.2.2: Please make sure that there are tests for
>      these functions that include surrogate pairs/codepoints above
#xFFFF.
> 
> [35] 7.3: It would be good to have a dedicated subsection 7.3 about
>      collations,..., and then section 7.4 with the actual functions.
>      (or any other structure that gives collation it's own subsection)
> 
> [36] *** 7.3: "the comparisons are inherently performed according to
some
> collation (even if that collation is defined entirely on code point
values
> or on the binary representations of the characters of the string)"
>      are "code point values" and "binary representation" alternatives
or
>      are they supposed to be the same? (the later would not be true in
>      the case of UTF-16, which should be pointed out)
> 
> [37] *** 7.3: "Strings can be compared character-by-character or in a
> logical manner, as defined by the collation."
>      This seems to imply that 'character-by-character' is not logical.
>      better change 'logical' to 'linguistically adequate' or so.
> 
> [38] *** 7.3 "For alignment with the [Character Model for the World
Wide
> Web 1.0], applications may choose collations that treat unnormalized
> strings as though they were normalized (that is, that implicitly
normalize
> the strings)."
>      This is somewhat misleading, in that early uniform normalization
>      should avoid having to compare strings that differ only in
> normalization.
>      This should be reworded carefully. Please also point out that
using
>      highest collation strength does not imply string normalization.
> 
> [39] *** 7.3: Using anyURIs to identify collations is the right thing
to
> do.
>       but there are several problems in how this is done in detail.
> 
> [40] *** 7.3: Having an anyURI to identify a collation by codepoint
order
>      (http://www.w3.org/2003/05/xpath-functions/collation/codepoint)
is
>      good. But there should at the minimum also be a predefined anyURI
>      for identifying the Unicode collation algorithm (without any
special
>      tailoring). Please note that this not necessarily means that
> implementations
>      have to support this algorithm (which we definitely would not
object
> to),
>      but it at least means that different implementations that all
> implement
>      that algorithm can interoperate.
> 
> [41] 7.3: "The XQuery/XPath static context includes A provision"
> 
> [42] *** 7.3: Rules for what collation to use: The current rules,
which
>      allow only one collation to be specified, raise an error if the
> collation
>      is not supported, and use anyURIs to identify collations without
any
>      mechanism for giving anyURIs to well-known collations, are bound
to
>      lead to interoperability problems. Collations should not be the
major
>      source of interoperability problems. With the current design,
even
>      vendors who want to be interoperable have no chance of doing so.
>      It will often be the case that e.g. a user wants just 'a French
>      collation'. How can this be indicated.
>      [we will send a separate mail about this issue to several lists
>       because we think that there is a potential for useful
coordination]
> 
> [43] *** 7.3: Context defines a single collation. But it may often be
>      desirable to have two 'default collations', in two different
senses:
>      a) different collations for matching (less precision) and sorting
>         (best precision possible)
>      b) different collations for internal operations and user-oriented
> operations
> 
> [44] *** 7.3: "There might be several ways in which a collation might
be
> specified in the XQuery/XPath static context. For example, XQuery
might
> provide syntax that specifies a default collation as part of the query
> prolog."
>      good ideas!
> 
> *** 7.3: The current proposal groups three different things into a
>      new concept called 'collation', which is different from what is
> usually
>      thought of as a collation. These are:
>      1) A collation in the traditional sense: every binary difference
> leads
>        to a non-equal match.
>      2) The use of different 'collations' to identify different
strengths
>        of the same collation (i.e. case-insensitive, accent-
> insensitive,...)
>      3) The use of 'collations' to identify character combinations
that
> serve
>        as single units in some respect in some languages (e.g. 'll'
and
> 'ch'
>        in traditional Spanish)
>      This has several problems:
>      [45] - The difference between 1) and 2), and the general use of
> highest
>             collation strength for sorting (to have deterministic
sorting)
>             and potentially lower for matching should be pointed out
> carefully.
>      [46] - Including 3) may make coordination with other efforts
somewhat
> difficult
>      [47] - Including 3) may make implementations somewhat difficult.
>             Although a given system (e.g. OS) may provide a range of
>             collations (in the 1) or 2) sense), the functionality in
3)
>             may not be available (e.g. via an API)
>      [48] - Including 3) may make specifications somewhat difficult.
>             There may be cases where it is unclear what the clusters
> should be.
>             For example, for French sorting with accents in the
reverse,
> are
>             the clusters the base letters followed by the accents? Or
is
> the
>             reverse consideration of accents ignored for this purpose?
>      [49] - This is way too important to be relegated to a note.
> 
> [50] *** 7.3: Using multiple-letter units for functions such as
'starts-
> with'
>      (independent of its definition via a collation), while
appropriate in
>      some cases, may not be that well established and tested. It
should be
>      carefully considered whether this functionality may not be too
> 'bleeding-edge',
>      and may not confuse users more than help, because there are too
many
>      cases where it is wrong, i.e. where character combinations are
taken
>      as single letters even if they are not, e.g. in foreign
loanwords,...
>      For example, a possible solution may be to use codepoint matching
> when
>      no collation is specified in the function rather than using the
> default
>      collation.
> 
> 
> [51] *** 7.3: "Some data management environments allow collations to
be
> associated with the definition of string items (that is, with the
metadata
> that describes items whose type is string). While such association may
be
> appropriate for use in environments in which data is held in a
repository
> tightly bound to its descriptive metadata, it is not appropriate in
the
> XML
> environment in which different documents being processed by a single
query
> may be described by differing schemas."
>      This is a very good point, but should also mention the fact that
a
> data-based
>      collation is not adequate for user needs.
> 
> 
> [52] *** 7.3: "Some data management environments allow collations to
be
> associated with the definition of string items (that is, with the
metadata
> that describes items whose type is string). While such association may
be
> appropriate for use in environments in which data is held in a
repository
> tightly bound to its descriptive metadata, it is not appropriate in
the
> XML
> environment in which different documents being processed by a single
query
> may be described by differing schemas."
>      This very much applies to sorting, but it looks somewhat out of
place
>      for 'character clusters' such as the traditional Spanish 'll' and
> 'ch',
>      because that seems to imply a linguistic unit, which means that
it
>      would be wrong to claim that 'el' is not an initial substring of
> 'elle'
>      if the later is not indeed Spanish.
> 
> [53] *** 7.3: Is there any case where e.g. element or attribute names
can
>      be treated as strings? How would they be sorted?
> 
> [54] *** 7.3: "It is possible to define collations that do not have
this
> property, for example a collation that attempts to sort "ISO 8859"
before
> "ISO 10646", or "January" before "February". Such collations may fail,
or
> give unexpected results, when used with functions such as
fn:contains()."
>      "this property": What property? Why 'fail'? That 'January' does
not
> contain
>      'ary' would be a consequence of the definition, not a failure.
Maybe
> it
>      would be better to say that for fn:contains and friends, using
the
>      codepoint collation in most cases produces more predictible
results
> than
>      using a specific collation.
> 
> [55] *** 7.3.1.1, last example: While in the preceeding example,
'equates'
>      is the right term, this is not necessary here. The only thing
that is
>      necessary is that the collation treats differences between 'ss'
and
>      sharp-s with less strength than differences in base letters (such
as
>      the final n). (there is also the case where the 'ss' <-> sharp-s
>      difference is at least as strong as the final 'n', and sharp-s <
> 'ss').
> 
> [56] *** 7.4 "The following functions are defined on these string
types."
>      which string types? As many as possible (up to anySimple and text
> node,
>      hopefully).
> 
> [57] *** 7.4.1: Is there a concat operation that includes
normalization
>      splicing at the contact point? This would be very helpful, and
> ideally
>      should be the default, because this may be the most efficient way
to
>      maintain a certain normalization. The same applies to string-join
>      and potentially other operations.
> 
> [57] *** 7.4.12/13: What about other transforms, such as
> katakana<->hiragana,...
> 
> [58] *** 7.4.6: "The first character of a string is located
>      at position 1, not position 0."
>      It is a pity that XQuery was not able to fix this problem. It
would
>      be good if there were a special section at the start of 7.4, or
>      somewhere else in an adequate place, that clearly explained the
>      issue of 1 origin for strings. Also, rather than writing things
>      such "beginning at position", it should always be "beginning at
>      character position", to make it easier for users to understand
>      that e.g. substrings are not identified by indicating boundary
>      positions between characters.
> 
> [59] 7.4.8/9: For continuity, fn:substring-before($string, "") should
>      return the empty string, and fn:substring-after($string, "")
>      should return $string. Rationale: The shorter a string is, the
>      earlier it generally matches. Thus, the empty string matches at
>      the start of a string.
> 
> [60] *** 7.4.11: There should be a reference to Unicode Standard Annex
#15
>      for the various normalization forms.
> 
> [61] *** 7.4.11: In the current Character Model, W3C normalization can
be
>      tested, but is not defined as a function. This probably can be
fixed
>      by specifying that the W3C normalization function first uses NFC,
>      and then prepends a space if the result is not yet in W3C
> normalization form.
> 
> [62] *** 7.4.11: In the light of the above, W3C normalization should
also
>      be made required to support.
> 
> [63] *** 7.4.11: What other normalization forms might be supported?
>      How would they be identified? How will the space of identifiers
>      be managed, to avoid conflicts?
> 
> [64] *** 7.4.12/13: The Unicode case mappings are now superseeded by
>      Unicode 4, see http://www.unicode.org/unicode/reports/tr21/.
> 
> [65] *** 7.4.12/13: It should be pointed out that mappings can change
>      the length of a string, and that lower(upper(s)) == s is not
>      guaranteed, nor is upper(lower(s)) == s, and that these functions
>      may not always be linguistically appropriate (e.g. Turkish i
>      without dot) or appropriate for the application (e.g. titlecase).
>      It should be said that in cases such as Turkish, a simple
translation
>      should be used first. It would be much better to have an uniform
>      approach for all languages, rather than having to special-case a
few
>      languages.
> 
> [66] 7.4.15: string-pad seems to be the wrong name, because it
suggests
>      padding to a certain length, e.g. string-pad("XMLQuery", 15)
would
>      return "XMLQueryXMLQuer", i.e. 15 characters. Something like
>      'multiply' seems more adequate.
> 
> [67] *** 7.4.16: It is unclear what these functions are supposed to do
>      with anyURIs/IRIs.
> 
> [68] *** 7.4.16: It is unclear what the case of $escape-reserved ==
false
>       is supposed to do. The example shows this as the identity
function,
>       which is probably not the point. Please give us a better
example,
>       so that we can understand what this is used for. It may be
better
>       ultimately to separate this into two functions, and remove the
>       $escape-reserved argument.
> 
> [69] 7.4.17: "The % character itself is escaped only if it is not
followed
>      by two hexadecimal digits": This seems dangerous. If "%20" is a
plain
>      payload, then the '%' has to be escaped, like everything else.
> 
> [70] 7.4.16: Gopher examples are very outdated. We suggest replacement
>      with something more people are familiar with.
> 
> [71] 7.5.1: 'reluctant' quantifiers: It may be better to use the Perl
>      term 'minimal'.
> 
> [72] 7.5.1: "In the absence of these quantifiers, the regular
expression
> matches the longest possible substring."
>      no, not in the absence of these quantifiers, but if the other
> (maximal)
>      set of quantifiers is used ('*?' is a quantifier, but in '*?',
'?' is
>      not a quantifer)
> 
> [73] *** 7.5.2: "Regular expression matching is defined on the basis
of
> Unicode code-points; it takes no account of collations."
>      It seems somewhat inadequate that fn:contains and friends use
> collations,
>      but regular expressions don't. But we are not sure which way the
> right
>      solutions is.
> 
> [74] 7.5.3: "An error is raised ("Invalid replacement string") if the
> value
> of $replacement contains a "$" character that is not immediately
followed
> by a digit 1-9 and not immediately preceded by a "/"."
>       "/" -> "\"
> 
> [75] *** 7.5.3: We have been told that there is a provision to replace
>      character strings with markup, but this is not discussed here.
>      We want to make sure this is available, because it is relevant
>      to get people away from using the PUA.
> 
> [76] 7.5.3: Why does fn:replace not provide for single replacements?
> 
> [77] 8.2.2/3: Boolean less-than and greater-than seem strange. On the
> other
>      hand, 'or' and 'and' seem to be badly missing.
> 
> 
> 
> This concludes the first part of these comments. We will send the
> rest of our comments tomorrow (planned around 3pm EDT July 8th).
> 
> 
> Regards,    Martin.
>

Received on Monday, 6 October 2003 10:20:51 UTC