This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 2424 - [XSLT 2.0] definition of alphanumeric in xsl:number format attribute
Summary: [XSLT 2.0] definition of alphanumeric in xsl:number format attribute
Status: CLOSED LATER
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 2.0 (show other bugs)
Version: Last Call drafts
Hardware: PC Linux
: P2 minor
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-29 07:36 UTC by Colin Adams
Modified: 2007-02-25 23:57 UTC (History)
0 users

See Also:


Attachments

Description Colin Adams 2005-10-29 07:36:51 UTC
I note that the definition of alphanumeric given for the format attribute does
not include all characters with the Unicode Alphabetic property.
Maybe the WG has already considered this, but I thought I'd draw attention to it.

I'm raising this now, rather than waiting for the CR to be issued, so I don't
forget it later.
Comment 1 Michael Kay 2005-10-29 09:10:30 UTC
The definition of alphanumeric (all characters in the Unicode letter and number
gorups) is unchanged since XSLT 1.0, and I'm not aware that it has caused any
problems. I don't think the WG has ever reviewed the definition.

The characters that are classified as alphabetic but not letters seem to consist
mainly of combining marks and signs, such as vowel signs. I've personally no
knowledge of whether such marks and signs are ever used in numbering sequences.
However, they are currently allowed in the format pattern as separator
characters, and if we moved them to the "alphanumeric" category then it seems we
would not only be creating a theoretical backwards incompatibility, we might
also be removing functionality. So I don't think we can consider doing this
without strong evidence that there is a practical need; and even if there is
such a need, I think we could justify making it a "version 3" requirement rather
than trying to squeeze a late change into 2.0.

Michael Kay
(personal response)
Comment 2 Michael Kay 2005-10-31 13:22:32 UTC
Resolution changed to "LATER" for scheduling purposes.
Comment 3 Jim Melton 2007-02-25 23:57:35 UTC
Closing bug because commenter has not objected to the resolution posted and more than two weeks have passed.