- From: <bugzilla@jessica.w3.org>
- Date: Wed, 03 Apr 2013 09:50:01 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21560 --- Comment #1 from Michael Kay <mike@saxonica.com> --- There are several levels of indirection involved here. However, it's true that the terminology isn't as consistent as it might be. The XQuery and XPath specs talk of the static context having "components" of which Statically Known Decimal Formats is one. The individual parts of this component (for example decimal-separator) are referred to both as "properties" and as "attributes". I think it would make sense to standardize on "properties". The names of these properties match the XQuery keywords used to set the properties in all cases but one: the keyword "digit" is used to set the property "digit-sign". There's no absolute necessity for the names to match: a different host language might use different keywords. But since XSLT uses the same keywords (in xsl:decimal-format) as XQuery, it would make sense to remove this single discrepancy. In F+O, the table in section 4.7.1 is a description of what the static context contains, and as such it should give the same information as the bullet points in section 2.1.1 of the XQuery and XPath specifications. As you point out, the names of the properties are different. The history here appears to be that XSLT 2.0 deliberately chose to distinguish the name of the property (or variable, as it was then called) from the name of the attribute used to set the property. When these properties were first added to the XQuery/XPath static context, the variable names from the XSLT 2.0 specification were used, but they were subsequently changed so that (in all cases but one) they matched the XQuery keywords. However this renaming never found its way into the F+O specification, probably because it was deemed "editorial". Unfortunately, simply using the XSLT/XQuery keywords throughout in F+O could cause some confusion (which may be why XSLT 2.0 had the indirection in the first place). For example, changing the sentence "A sub-picture must contain at least one character that is an optional-digit-sign or a member of the decimal-digit-family." to "A sub-picture must contain at least one character that is a digit or a member of the decimal-digit-family." would be seriously misleading, since "digit" here refers to the character conventionally represented as "#". So I think the answer is to retain the indirection, but to provide a mapping from property names to variable names in the table in 2.1.1. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Wednesday, 3 April 2013 09:50:07 UTC