> That being the case, isn't the current set of productions for
> SequenceType ambiguous?
I agree with you, there is a reserved word problem with type names.
Generally we have been happy to have reserved words in XQuery but not in
XPath, and I don't think we've achieved that here.
>
> If neither of those is the case, one method of clarifying this would
> be to make those ItemTypes that are actually node types look like
> (node) KindTests (production [31]), so you'd have node(),
> processing-instruction() and so on. This could be extended to include
> element() and attribute(), perhaps adopting the same syntax as
> processing instruction tests to provide the name of the node:
>
> element('foo')
>
> would mean the same as:
>
> element foo
>
We've been discussing within the XSL WG how to incorporate type matching
into the XSLT pattern syntax, and we have ideas that run along these lines,
but no detailed proposal yet.
>
> Another thing here is how you match elements and attributes if you use
> an ElemOrAttrType.....
I'll leave this part to people who understand schemas better than I do.
>
> Personally, I'd like to see the syntax used here unified with the
> syntax used in XSLT in match patterns. It strikes me that you're doing
> a similar kind of thing as match patterns here: putting together a
> test that identifies the kind of things that are allowed in a
> sequence. Perhaps an alternative, therefore, would be to use type(),
> say, to indicate a type and have things like:
>
> type('xs:date') refers to the built-in Schema type date
> @*? refers to an optional attribute
> * refers to any element
> office:letter refers to an element with a specific name
> *[type('po:address')]+ refers to one or more elements of the given
> type
> node()* refers to a sequence of zero or more nodes of
> any type
> item()* refers to a sequence of zero or more nodes or
> atomic values
>
We've been toying with such ideas in XSL WG. Thanks for the contribution.
Michael Kay