This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
7.1.6 The fs:distinct-doc-order-or-atomic-sequence function "$item as node *" s/node/item/, surely. STA / rule 1 / premise 2 Type <: node* node* is not a valid Formal Type. Change to [[ node()* ]]_sequencetype ?
(In reply to comment #0) > > STA / rule 1 / premise 2 > Type <: node* > node* is not a valid Formal Type. > Change to [[ node()* ]]_sequencetype ? Or (italicized) NodeType*, as in 7.2.4.
Fixed as suggested, using the NodeType* option.
On second thought, NodeType* probably isn't what you want. E.g., it can't derive a type that matches a sequence of different kinds of nodes. So I fall back to my first suggestion, [[ node()* ]]_sequencetype (or you could use its expansion).
Alright, back to the other option. - Jerome
(In reply to comment #3) > "The fn:boolean function as described in the [Functions and Operators] document > takes an empty sequence, a sequence of one or more nodes, or a singleton value > of type .... All other values are illegal." > No, fn:boolean <em>as described in the F+O doc</em> handles a wider set of > inputs. If you want the static typing to accept a narrower set of types, > fine, but don't make it sound like they're in agreement. I have clarified the distinction between the dynamic and static type restrictions. > Also, the list of singleton types is missing xs:anyURI. The Rec fixed this in the inference rule, but not in the preceding prose. > Also, NodeType+ probably isn't what you want. See Bug 1747, comment #3. Changed to [[ node()+ ]]_sequencetype.
Sorry, wrong Bug.