This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
On queries such as: for $i as xs:integer+ in (1, 2, 3) return $i some/every $i as xs:integer+ in (1, 2, 3) satisfies $i Saxon 8.7.1 SA raises the question of what the type declaration actually applies on, by reporting XPTY0004, "Cardinality of range variable must be exactly one." What does the type declaration apply on? One alternative is that Saxon is right, that the type declaration is applied on each tuple binding individually. If this is the case, it makes no sense to specify a cardinality other than exactly-one, in practice meaning that specifying the type empty-sequence(), and cardinality +/* makes no sense and should perhaps be statically forbidden. The other alternative is that the type declaration applies on the initial binding sequence as a whole, which must be the case of 'let' bindings. An advantage of this alternative, is that the user can require a for/let/some clause to be run at least once, by specifying a cardinality which disallows the empty sequence. The XQTS isn't of much guidance here. There are no tests specifying a cardinality for 'for' tests(although tests involving empty-sequence exists), and there are no type-declaration tests for quantifications in the latest release. I would with little doubt say that the latter is the correct way, but Saxon is in that case stands out with having the exact opposite interpretation. Is an editorial clarification appropriate? That at the end of the two type-declaration paragraphs for 'for' and some/where is added "The type declaration applies to the binding sequence as a whole, not on each item individually." One could argue that for and some/every should be consistent in this area, as mentioned by Michael Kay in private mail. Frans
I think the spec is fairly clear at present that the type applies to the variable (ie to each individual item in a for clause) so saxon (and xq2xsl) have (currently) the correct interpretation. 3.8.1 says: ...Each variable bound in a for or let clause may have an optional type declaration, which is a type declared using the syntax in 2.5.3 SequenceType Syntax. If the type of a value bound to the variable does not match the declared type... The change to instead type the sequence would as you point out be more expressive as it would give sensible meanings for the cardinality indicators, but if that change were made I think the position of the as clause would need to move for $i in (1,2,3) as xs:integer* so that "as" keeps its role of separating the value and the type. David
I think that in either case, doing such a grammar change is not an option due to it being too intrusive at this stage. I neither think it's necessary because parsers can handle sequence type/primary expressions appearing next to each other and already do so in other situations. Also, from what I can tell the 'in' keyword in either way appears between the type and value: for $i as xs:integer+ in (1, 2, 3) return $i Frans
> a grammar change is not an option I agree its too late for changes (although of course I'm not on the WG in any case) but I think the proposed change in meaning would be very confusing without a grammar change. > from what I can tell the 'in' keyword in either way appears between the type and value: I read the as expression as typing the _variable_ . The clause is <variable> as <sequence type of value bound to variable> so "in" doesn't come into the typing at that level. I think that fits with most other uses of sequence type in xquery. You want the clause to be read as <variable> as <sequence type of sequence> in <sequence> which inverts the order of the subterms putting the type before the value to which it refers. I'm sure compilers could parse this, but I am less concerned about them, more about people:-) I think it would be confusing (which is a shame as I agree it would be useful to have the functionality). David
I think the spec is clear that you can write for $i as xs:integer* in (1 to 5) return ... and there seems to be no justification for Saxon rejecting this as an error. It's clear that the sequenceType applies to the value bound to the variable. This means that the occurrence indicator is redundant but not wrong. I don't think there is any good reason for the spec to allow an occurrence indicator here, however. It would be a straightforward change to the syntax to allow only an ItemType rather than a SequenceType, and I would personally be in favour of making this change. Michael Kay
Why not change the type declaration to apply to the binding sequence as a whole, instead of the items individually? As mentioned earlier, this makes the type declaration more powerfull since the user can control how the mapping(for/every/some) is run. That is, if it's run at least once, exactly once, or any amount. I can't see any drawbacks with going that route. I don't see any fundamental differences for implementors to implement it(but otoh, my experience is surely limited), nor do I find it more intrusive than changing the grammar. I would with interest read about potential drawbacks for letting the type declaration apply to the sequence as a whole.
Frans, The Query working group discussed this issue on June 6, 2006. The consensus of the group is that a type specification in a for-clause applies to the individual values bound to the iteration variable, and that this is clearly specified. Throughout the XQuery language, "expr as type" is an assertion that the given expression has the given type, and a for-clause is no exception. Of course, this means that adding an occurrence indicator to this type specification serves no purpose since the iteration variable is always bound to a single item. Nevertheless, for consistency the working group prefers to use the same syntax for a type specification in a for-clause that is used for all other type specifications. Therefore the group does not plan to make any changes in response to this issue. If you accept this resolution of the issue, please mark this Bugzilla entry as Closed. Regards, Don Chamberlin (for the XQuery working group)
I can understand consistency on the grammar level, and hence as a slight consequence, consistency in implementation approach. But I can't see the consistency argument from a user's perspective. Sure, the user is free to specify an occurrence indicator and hence it is consistent with other cases involving SequenceTypes, but it makes absolutely no sense. If the user specifies an occurrence indicator, it means one thing: he/she has misunderstood how the expression works. By silently accepting it, the language accepts code which does not do what the user expects it do -- the same effect as for example accepting non-well formed XML. The whole point of error messages is to avoid this kind of situations. It wouldn't surprise if a large part of the reluctance is because of the potential invasive grammar changes. I would agree that the grammar changes are (easily too) invasive at this stage. I neither think it would be straight forward, because one cannot simply replace SequenceType with ItemType, since that would exclude empty-sequence(). However, an alternative is to implement the error on a higher level: "It is a static error if the declared type allows anything but one item[error code]." Functionally, it would achieve the same but without an invasive grammar change. Yes, it would beg for the question "but why does the grammar allow it then?" and hence make the spec look illogical. I'd say that is easily a worthy sacrifice, considering that XQuery, which easily will stay for a decade, will now have a characteristic that users will fall over. Few read the spec, but very many use the language. I still neither see why one wouldn't choose to let the type declaration apply on the sequence as a whole. I would have full understanding for a consistency-argument in that case(e.g, a sequence type that actually applies to a sequence), and it wouldn't have the problem of having to make an occurrence indicator disappear because it would have a purpose. Nevertheless, I don't re-open because I don't feel I can judge in this matter, because I only know my view on this. However, if anyone who participated on the teleconference feel that implementing the error on a higher level as described above could be an acceptable alternative -- do feel free to reopen or discuss this further. Frans