[Bug 8006] New: wrong static typing rule for transform expression?

http://www.w3.org/Bugs/Public/show_bug.cgi?id=8006

           Summary: wrong static typing rule for transform expression?
           Product: XPath / XQuery / XSLT
           Version: Candidate Recommendation
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Update Facility
        AssignedTo: jonathan.robie@...
        ReportedBy: markos_za@...
         QAContact: public-qt-comments@...


It seems to me that a static typing regarding the transform expression is too
strict and probably wrong. Specifically, the rule requires that the source
expression for each copy variable have a static type of node() (i.e., exactly
one node).

If this rule were to be enforced, then the second example given in section
2.4.5 of the XQUF spec would fail. Furthermore, many of the transform tests in
the XQUF test suite would fail as well.

Finally, this rule is much stricter that the static typing rules of other
updating expressions. For example, consider the target expression of a rename
expression. It is a runtime error if this expression returns more than 1 node.
However, its static type does not put any constraints on the cardinality. Why
is transform different in this respect?


--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=8006


Michael Kay <mike@...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mike@...




--- Comment #1 from Michael Kay <mike@...>  2009-10-22 15:51:07 ---
Personal response:

The rule given in the prose (2.4.5, rule 1b) is "The result of evaluating the
source expression must be a single node", and the error if it isn't is a type
error. It's a principle of static typing that all type errors are detected
statically.

It's true that the second example query would fail static typing. The vast
majority of queries that people write would fail static typing, but fortunately
not many implementations enforce static typing. I think your comment amounts to
saying that static typing creates significant usability problems, which is
something the working group already knows. We all have different ideas for the
solution to that problem, but making the required type of an expression in the
static semantics looser than the rules for its dynamic type isn't one of them.

Section 4.5.6 includes the analogous example

insert node <x/> into //a

which is a static type error because //a isn't known to return a single node.

The absence of such a rule for "rename" would appear to be an oversight. This
is also a type error, and with static typing enabled, potential type errors are
always reported as static errors.


--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=8006





--- Comment #2 from Markos Zaharioudakis <markos_za@...>  2009-10-22 16:48:53 ---
I don't think that the example

insert node <x/> into //a

would fail static typing, because the ST rule for the target expression of
"insert into" is element*. In general, except for transform, the ST rules for
all of the other updating expressions do not place a constraint on node
cardinality. So, I was thinking that the transform rule may have a typo error:
node() instead of node()*.


In any case, a spec shouldn't include an example (like the one in 2.4.5) that
contradicts the rules of the spec itself, right? So, either the transform ST
rule should change, or the example in 2.4.5 (and several tests in the XQUF test
suite as well) be fixed.


--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=8006





--- Comment #3 from Michael Kay <mike@...>  2009-10-22 16:58:44 ---
>In any case, a spec shouldn't include an example (like the one in 2.4.5) that contradicts the rules of the spec itself, right?

There are many examples in the XQuery specification that fail static typing.
Our usual approach is to add a note to that effect alongside the example. It
would be unreasonable to require all examples to pass static typing, since most
implementations do not support the feature, and most users can therefore use
such example code without any trouble.


--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=8006


Jonathan Robie <jonathan.robie@...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
           Keywords|                            |needsAction, WGDecision
         Resolution|                            |FIXED




--- Comment #4 from Jonathan Robie <jonathan.robie@...>  2009-11-05 18:09:51 ---
The static typing behavior of updates is consistent with the rest of the
language, and we have no agreement to change it.

I will add a NOTE to the document mentioning that the example does not pass
static typing.


--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=8006


Michael Dyck <jmdyck@...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdyck@...




--- Comment #5 from Michael Dyck <jmdyck@...>  2009-11-05 18:17:47 ---
(In reply to comment #0)
>
> For example, consider the target expression of a rename
> expression. It is a runtime error if this expression returns more than 1 node.
> However, its static type does not put any constraints on the cardinality.

Actually, the STA rule for RenameExpr requires that the TargetExpr's type have
cardinality zero-or-one.


--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=8006





--- Comment #6 from Markos Zaharioudakis <markos_za@...>  2009-11-05 19:46:37 ---
(In reply to comment #5)
> (In reply to comment #0)
> >
> > For example, consider the target expression of a rename
> > expression. It is a runtime error if this expression returns more than 1 node.
> > However, its static type does not put any constraints on the cardinality.
>
> Actually, the STA rule for RenameExpr requires that the TargetExpr's type have
> cardinality zero-or-one.
>

Yes, you are right. I was reading the rule wrong. The rule for rename has the
line:

statEnv |- Type1 <: (attribute *| element * | processing-instruction *)?

I was interpreting the "*" as an occurrence indicator instead of a name
wildcard.

Sorry for the trouble.


--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.