RE: SequenceTyping matching of 'element QName'

I've got some sympathy with the ideas here: I have been trying to press for
changes that bring the type matching mechanisms and the path expressions
(and match patterns) more closely together, at the moment they feel very
disjoint. They use different syntactic styles and they don't compose well
with each other.

I have also had a feeling at the back of my mind that XSLT patterns are
being used as a sort of type mechanism: pattern matching categorizes
elements according to their structural properties by means of instance-level
predicates in a way that is not that dissimilar from the way a schema
processor allocates types by examining the structure of the content. In XSLT
we have a requirement to allow template rules to be driven by schema types,
and the current syntax for achieving this is pretty dire.

I think that typeswitch is so central to the static typing approach that the
ideas you suggest for extending it wouldn't fly. A more general kind of
switch that can match on properties other than type sounds an interesting
idea: it could get very close to xsl:apply-templates. I think few people
would want to add such a major piece of functionality to Query version 1.0
at this stage of development.

Cheers,

Michael Kay


> 
> 
> The draft spec (2.4.2) says that to match a SequenceType
> of form ("element" |  "attribute") ElemOrAttrType? when 
> ElemOrAttrType is a QName:
> 
>    The QName must be an element or attribute name that is
>    found in the   in-scope schema definitions. The match is
>    successful only if the given element or attribute has the
>    required name and also conforms to the schema definition
>    for the required name.
> 
> And Conformance section 2.5.2.1 Basic XQuery says:
> 
>    If any SequenceType contains an ElemOrAttrType, a Basic XQuery
>    implementation raises a static error.
> 
> This is very unfortunate, since it is very useful to be able 
> to match a node against a specific element tag in a 
> typeswitch.  I'd go so far as to say that this guts most of 
> the usefulness of typeswitch.  The alternatives seem to be a 
> lot more tedious and verbose.
> 
> It is especially unfortunate for me since the examples I use 
> in my article "Generating XML and HTML using XQuery" (available as
> http://www.gnu.org/software/qexo/XQ-Gen-XML.html) now 
> suddenly because non-conforming without a matching Schema.
> 
> Please revisit this.
> 
> A suggestion, which has the advantage that it provides much 
> of the power of XSLT's template processing:  Add a 
> pseudo-type for matching against a PATTERN:
>    "matching" PathExpr
> I don't know if I'd go so far as to allow this everywheer 
> that SequenceType is currently allowed, but I'd certainly 
> allow it in the context of typeswitch:
> 
> typeswitch ($node)
>    case matching meta/title return "saw title inside a meta-tag"
>    case matching title[@id] return "saw a title with an 'id' 
> attribute"
>    case matching title return "saw title not in a meta-tag
>    default return "saw some other tag"
> 
> Perhaps allow "match" as a synonym for "case "matching" to 
> make it less verbose:
> 
> typeswitch ($node)
>    match meta/title return "saw title inside a meta-tag"
>    match title[@id] return "saw a title with an 'id' attribute"
>    match title return "saw title not in a meta-tag
>    default return "saw some other tag"
> 
> With this feature XQuery can do most of what XSLT can do, and 
> much less verbosely.
> 
> Perhaps adding the full PathExpr may be a bit much for Basic 
> XQuery 1.0, but allowing 'matching NodeTest' may be a good start
> -- 
> 	--Per Bothner
> per@bothner.com   http://www.bothner.com/per/
>

Received on Friday, 18 October 2002 08:13:52 UTC