W3C home > Mailing lists > Public > public-qt-comments@w3.org > January 2004

[XSLT2.0]

From: Igor Hersht <igorh@ca.ibm.com>
Date: Sun, 11 Jan 2004 17:01:13 -0500
To: public-qt-comments@w3.org
Message-ID: <OF93798E41.187675FF-ON85256E18.0075FBB7@ca.ibm.com>





SUGGESTION 1:
3.10.3 Stylesheet Import.
...
"The order of import precedence (lowest first) is D, B, E, C, A.

In general, a declaration with higher import precedence takes precedence
over a
declaration with lower import precedence. This is defined in detail for
each kind of
declaration"

It is not clear for me why "In general". Why we cannot have it
as a common rule.I don't understand why sometimes we use import
precedence (e.g. in 9.5 Global Variables and Parameters) sometimes
don't (e.g. in 16.4.1 Defining a Decimal Format). I think it should
be explained. If there is no any technical reason to have it just "In
general" ,
we should have common rules - we should use import precedence
(not using import precedence as a "common rule" makes no sense because it
would
have the same functionality as xsl:include).

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.

SUGGESTION 3:
16.4.1 Defining a Decimal Format

Add attribute lang? = { nmtoken }.
The rules for the attributes are the same as for
this attributes in other elements (e.g. xsl:number).
lang attribute should control default values for attributes:
decimal-separator, grouping-separator, infinity minus-sign, NaN,
percent, per-mille, zero-digit.
(e.g. text "decimal-separator specifies the character used for the
decimal-separator-sign;
the default value is the period character (.)"
should be replaced with
decimal-separator specifies the character used for the
decimal-separator-sign;
the default value is default for a given language".

SUGGESTION 4:
20 Serialization normalize-unicode?  attribute of the xsl:output element
Problem:
Not clear which normalization forms to use. "NFC"?
Why we should have "NFC" only, if we can support others as in
fn:normalize-unicode?

Solution:
normalize-unicode? = string
The attribute should follow the rules of the second
argument($normalizationForm   )
of the fn:normalize-unicode
(http://www.w3.org/TR/xquery-operators/#func-normalize-unicode)


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
Received on Sunday, 11 January 2004 17:09:24 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:13:55 UTC