This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
<test-case name="millisecs-019" xmlns="http://www.w3.org/2010/09/qt-fots-catalog"> <description>Fractional seconds: non-digit presentation modifier </description> <created by="Michael Kay" on="2016-07-21"/> <test><![CDATA[format-time(xs:time('12:01:01.123'), "[fi]")]]></test> <result> <assert-type>xs:string</assert-type> </result> </test-case> I would like to raise an error here. I think this case falls under "If the first presentation modifier contains no Unicode digit, then the output is implementation-defined." Presumably this allows me to raise an error?
The stated policy for format-number/date/time/integer etc is that if the picture string conforms to the defined syntax then you fall back to a default representation rather than raising an error. ยง9.8.4: In general, the use of an invalid $picture, $language, $calendar, or $place argument results in a dynamic error ([err:FOFD1340]). By contrast, use of an option in any of these arguments that is valid but not supported by the implementation is not an error, and in these cases the implementation is required to output the value in a fallback representation. Which is why the test assertion is simply that the result must be a string. I think there are good interoperability reasons for sticking to this policy.
I didn't see the general policy so will mark as INVALID. I don't really see how interoperability can be expected in cases like this where the result is "anything goes".
The thinking is that formatting is producing output for human consumption. If two processors can handle the same input and present it intelligibly to human readers, then it's not the end of the world if the output isn't pixel-for-pixel the same. It's a much bigger problem for stylesheet authors if they have to cope with processors that don't handle the input at all.