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 12280 - [FO 3.0], Section 4.5.1: Lack of clarity in the definition of a format-token
Summary: [FO 3.0], Section 4.5.1: Lack of clarity in the definition of a format-token
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 3.0 (show other bugs)
Version: Working drafts
Hardware: PC Linux
: P2 normal
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: 2011-03-10 10:48 UTC by O'Neil Delpratt
Modified: 2012-01-19 09:12 UTC (History)
0 users

See Also:


Attachments

Description O'Neil Delpratt 2011-03-10 10:48:26 UTC
In the description of the format-token criteria, it does not clearly state what is a format-token. This would help in the understanding of the bullet point "Any other format token indicates a numbering sequence...".

To help in the clarification please see an email I received from Christian Grun:

1) format-integer(1, 'bo')

This query is accepted, as the character 'b' is interpreted as format
token that "indicates a numbering sequence in which that token
represents the number 1 (one)" [1]. The trailing "o" seems to be
ignored; I would rather have expected it to be interpreted as optional
"format modifier".

2) format-integer(1, 'oo')

This query is rejected with the message "The format modifier is not
valid". My assumption that the first "o" is interpreted as an optional
"format modifier"?

3) format-integer(1, 'boo')

The (expected) error of this query might underline the assumption for Query 2.

4) format-integer(1, 'bb')

This query is accepted, and the trailing 'b' is ignored (which is
probably ok, as I'm not sure if this case is reflected by the spec).


To arrive at a consistent behavior, it might suffice to decide how
trailing, unparsed characters are to be treated, and to always
interpret the first character(s) as "primary format token".
Comment 1 Michael Kay 2011-03-10 14:04:03 UTC
To add an observation:

(a) The rules for how to handle format-tokens were taken from the XSLT 2.0 spec, where a format-token is described as "a maximal sequence of alphanumeric characters". The definition itself wasn't transferred to F+O.

(b) We can't use exactly the same definition in F+O because the format modifier follows directly after the format token. This was to align with format-date and friends - which has the same problem, and we can't easily change the syntax for compatibility reasons.

It's not particularly elegant, but I propose that the format-token is defined by changing this sentence:

* A picture consists of a primary format token, followed by an optional format modifier.

to read

* A picture consists of a primary format token, followed by an optional format modifier. If the picture is two or more characters in length and the final character is one of those permitted as a format modifier, then the primary format token consists of the entire picture except for its final character; otherwise the primary format token is the entire picture.

Should also add a similar clarification to format-date.
Comment 2 Michael Kay 2011-03-15 15:54:55 UTC
The WG accepted the proposal in comment #2
Comment 3 Michael Kay 2012-01-19 09:12:03 UTC
For a continuation of this issue, see bug #14858