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 2321 - [XSLT 2.0] format-date/dateTime/time() fallback prefixes
Summary: [XSLT 2.0] format-date/dateTime/time() fallback prefixes
Status: CLOSED FIXED
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: erratum
Depends on:
Blocks:
 
Reported: 2005-09-29 16:09 UTC by Colin Adams
Modified: 2007-04-17 14:32 UTC (History)
0 users

See Also:


Attachments

Description Colin Adams 2005-09-29 16:09:03 UTC
The text looks both a little vague, and slightly off the ball to me.
Firstly:
"If the fallback representation uses a different calendar from that requested,
the output string must be prefixed with [Calendar: X] where X identifies the
calendar actually used. The string Calendar should be localized using the
requested language if available. "

This might result in a very odd string if the language concerned uses
right-to-left ordering. You will end up with something vaguely like:
[radnelaC: X]
Judging by the Hebrew examples, this is not what is intended.

Secondly, I am not 100% sure where the [Language: Y] string comes when the
[Calendar: X] string is also needed. Which comes first?
Comment 1 Michael Kay 2005-09-29 17:02:04 UTC
The working groups decided at the end of their meeting an hour ago to defer any
new issues for consideration after the specs reach Candidate Recommendation
status, unless they are trivial things that the editors can deal with without
delaying the process of reaching CR. I am therefore closing this with the
category "LATER": this doesn't mean the comment will be lost, merely schedules
it for consideration during the next phase of development.

A personal response to the specific comment: I think the general tenor of the
text in this section is to encourage implementors to localize the output as
intelligently as they are able. We don't want to be prescriptive about how this
is done. 

Michael Kay
Comment 2 Jim Melton 2007-02-25 23:57:14 UTC
Closing bug because commenter has not objected to the resolution posted and more than two weeks have passed.
Comment 3 Michael Kay 2007-04-03 22:53:39 UTC
Despite Jim Melton's administrative closure of this bug, the WG returned to it on 15 March 2007, recognizing that it had not received proper attention. I took at action (A-2007-03-15-004) to editorially improve the section, with the general tenor being that the implementation should be free to present the information as best it can.

Proposal: change the text:

If the fallback representation uses a different calendar from that requested, the output string must be prefixed with [Calendar: X] where X  identifies the calendar actually used. The string Calendar should be localized using the requested language if available. If the fallback representation uses a different language from that requested, the output string should be prefixed with [Language: Y] where Y  identifies the language actually used. The string Language may be localized in an implementation-dependent  way. 

to:

If the fallback representation uses a different calendar from that requested, the output string MUST identify the calendar actually used, for example by prefixing the string with [Calendar: X] localized as appropriate to the requested language. If the fallback representation uses a different language from that requested, the output string MUST identify the language actually used, for example by prefixing the string with [Language: Y] localized in an implementation-dependent way. 
Comment 4 Sharon Adler 2007-04-17 13:48:29 UTC
The WG met on 17 April 2007 at the F2F at Red Hat and reviewed and accepted M. Kay's proposal with the addition of explicitly stating what "calendar X" and "language Y" actually stands for. 
Comment 5 Sharon Adler 2007-04-17 14:32:05 UTC
This completes erratum E4.