- From: Igor Hersht <igorh@ca.ibm.com>
- Date: Thu, 1 Apr 2004 17:11:10 -0500
- To: Henry Zongaro <zongaro@ca.ibm.com>
- Cc: public-qt-comments@w3.org
I agree, but I think it could be good idea to mention that string after
second tag-separator
could be used in implementation defined way.
I guess that at least Java processors would use the sting the same way
which is to
map to the variant.
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
Henry
Zongaro/Toronto/I
BM To
Igor Hersht/Toronto/IBM
04/01/2004 01:41 cc
PM public-qt-comments@w3.org
Subject
Fw: [XSLT2.0]
Igor,
In [1] you submitted the following comment:
Igor Hersht wrote on 2004-01-11 05:01:13 PM:
> SUGGESTION 2:
>
> lang attribute used in xsl:number(12 Numbering)
> and xsl:sort (13.1 The xsl:sort Element) language argument used in
> date formatting functions (16.5 Formatting Dates and Times)
> format-dateTime, format-date, format-time
> The attribute and arguments have common rules "The effective
> value of the attribute must be a value that would be valid for
> the xml:lang attribute"
> (http://www.w3.org/TR/1998/REC-xml-19980210#sec-lang-tag).
> The specs define precisely mapping from value of the attribute to ISO 639
> language
> and ISO 3166 country codes.
>
> Problem Mapping from a value of the attribute to a variant code is not
> specified.
>
> Solution
> A variant code should be constructed from the substring after the second
> tag separator
> by converting the substring to upper case and replacing all '-'
characters
> with '_'.
> The variant code is ignored, if implementation cannot find a resources
for
> the variant code
> with given ISO-639 language and ISO-3166 country code. A warning message
> should be issued
> in this case. Changes in behavior caused by the variant are
implementation
> defined.
Thank you for submitting your comment.
The XSL Working Group discussed your comment. The working group
decide not to make any change to XSLT 2.0. The working group felt that this
sort of information about variants wouldn't be appropriate in XSLT 2.0, but
would be more appropriate in a specification that is a successor to RFC
3066.
May I ask you to confirm that this is an acceptable response to your
comment?
Thanks,
Henry
[1]
http://lists.w3.org/Archives/Public/public-qt-comments/2004Jan/0019.html
------------------------------------------------------------------
Henry Zongaro Xalan development
IBM SWS Toronto Lab T/L 969-6044; Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com
Received on Thursday, 1 April 2004 17:13:26 UTC