- From: Igor Hersht <igorh@ca.ibm.com>
- Date: Tue, 13 Jan 2004 15:30:48 -0500
- To: "Kay, Michael" <Michael.Kay@softwareag.com>
- Cc: public-qt-comments@w3.org
Thank for your response. It makes perfect sense . I just have a different opinion on some issues. (It is just my private opinion). >We made the decision to go for a language-independent mapping of >lower-case upper-case and vice-versa. Then one has to remove notes from 7.4.7 fn:upper-case and 7.4.8 fn:lower-case where you are saying explicitly that fn:upper-case and 7.4.8 fn:lower-case are language dependent. You would need fn:upper-case fn:lower-case functionality for other staff (e.g. xsl:number) anyway. I don't also understand why we cannot permit people to have richer (i18n friendly) functionality. (It could be just permission set of languages could be implementation defend and a "default" could a language independent one) > I don't think we want to be too prescriptive in terms of the >collation algorithms that vendors use. I would agree if it would be difficult to implement . Otherwise unambiguous implementable specs is a good idea. > would suggest that substring-before($s1, $s2) is defined as: ... I don't understand the rational of using XSLT specific definitions for string matching if it has already has been defined by common Unicode specs. >I think the rules for starts-with, contains, and ends-with are >unambiguous I think they are ambiguous starts-with("-a", " a") true a false? Igor Hersht XSLT Development IBM Canada Ltd., 8200 Warden Avenue, Markham, Ontario L6G 1C7 Office D2-260, Phone (905)413-3240 ; FAX (905)413-4839 "Kay, Michael" <Michael.Kay@soft To: Igor Hersht/Toronto/IBM@IBMCA, wareag.com> <public-qt-comments@w3.org> cc: 01/13/2004 10:57 Subject: RE: [XQuery 1.0 and XPath 2.0 Functions and AM Operators] A personal response, prior to any WG discussion of the comments: > > SUGGESTION 1: > > 7.4.7 fn:upper-case and 7.4.8 fn:lower-case > How we can find what language to use? From default collation? > It is not going to be flexible if from default collation. > Possible solution- second optional parameter xml:lang We made the decision to go for a language-independent mapping of lower-case upper-case and vice-versa; we felt that providing language-dependent mappings was outside the 80/20 cutoff. Remember that there is plenty of provision for additional functions to be provided outside the core library. > > SUGGESTION 2: > > 7.5 Functions Based on Substring Matching > The rules are ambiguous if there are ignorable collation units. > > example > '-' is ignorable for some collations. substring-before("a-b", > "b") returns "a" or "a-"? > > Matching rules should be more precise and based on > http://www.unicode.org/unicode/reports/tr10/> #Searching > (e.g. > minimal or maximal. > For all positive i and > j, there is no match at Q[s-i,e+j].) > I don't think we want to be too prescriptive in terms of the collation algorithms that vendors use. But I agree with you that the rules for substring-before and substring-after could be clearer. I would suggest that substring-before($s1, $s2) is defined as: substring($s1, 1, $n -1) where $n is the lowest integer that satisfies starts-with(substring($s1, $n), $s2) And substring-after($s1, $s2) is defined as: substring($s1, $n + string-length($s2)) where $n in the lowest integer that satisfies starts-with(substring($s1, $n), $s2) (these rules will need augmenting for the case where there is no match). I think the rules for starts-with, contains, and ends-with are unambiguous. Michael Kay
Received on Tuesday, 13 January 2004 15:35:39 UTC