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 28948 - [QT3TS] K2-Serialization-29: whitespace in option declarations
Summary: [QT3TS] K2-Serialization-29: whitespace in option declarations
Status: RESOLVED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQuery 3.1 (show other bugs)
Version: Last Call drafts
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Jonathan Robie
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-07-14 22:52 UTC by Michael Kay
Modified: 2015-07-16 15:59 UTC (History)
2 users (show)

See Also:


Attachments

Description Michael Kay 2015-07-14 22:52:32 UTC
Test K2-Serialization-29 tests that leading and trailing whitespace is permitted in option declarations, e.g.

declare option output:indent "    yes    ";

and assumes that it is permitted. But I can't see anything in the spec that allows one to assume this. Certainly in the serialization parameter file, the schema derives the yesNo type as an enumeration restricting xs:string, and xs:string does not normalize whitespace.

Another example is

declare option output:method "  Q{}xml	"

The spec is clear that character references are allowed and that EQName syntax is allowed, but there's nothing that explicitly allows the whitespace. The EQName syntax itself doesn't.
Comment 1 Josh Spiegel 2015-07-14 23:06:34 UTC
Isn't yesNo a restriction on token?

  <xs:simpleType name="yes-no-type">
    <xs:restriction base="xs:token">
      <xs:enumeration value="no"/>
      <xs:enumeration value="yes"/>
    </xs:restriction>
  </xs:simpleType>

And as I recall, method is a union type that includes xs:string.  So I suppose "  Q{}xml&#x9;" would be a string.
Comment 2 Michael Kay 2015-07-15 01:24:07 UTC
>Isn't yesNo a restriction on token?

So it is. I had been looking at other parameters, e.g. method and encoding, that are defined as restrictions from xs:string, and somehow assumed they would all be the same.

I think we need to sort out the inconsistency.

Also the fact that the option parameter declaration allows EQNames but the schema doesn't.

Changing this to a spec bug.
Comment 3 Michael Kay 2015-07-15 01:31:57 UTC
The schema for the method type says it is a union between an xs:string enumeration of the six specific values xml, html, text, json, etc, and xs:QName retricted to contain a colon. When two branches of a union have different whitespace facets, you have to apply different whitespace normalization rules when testing against each branch of the union (IIRC). So value="xml" doesn't allow whitespace, but value=" my:method " does. And when it comes to 

declare option output:method " Q{uri}method ";

your guess is as good as mine, because it's not in the schema at all. Oh, these sordid details.
Comment 4 John Snelson 2015-07-16 15:59:46 UTC
DECISION: Change the schema to collapse whitespace in all cases except where WS is significant (ie: item separator). Restore the equivalence of option declarations and parameter documents by also allowing EQNames in the parameter document.