I've looked at a sample of these and I'm not convinced. XPDY0002 is a dynamic error, and I think you should only raise a dynamic error for an expression that contains no static errors.

K2-NodeTest-10
document(*)
is a call on an undefined function - a static error

K2-NodeTest-19 
document-node(schema-element(thisTypeIsNotRecognizedExample.Com))
uses an element name that's not in an imported schema - a static error

K2-NodeTest-23 
element(notBound:ncname)
uses an undeclared namespace prefix - a static error

and a few others in the same vein. I don't see how a dynamic error can be justified for any of these cases.

In all these examples there is an implicit use of the context item.  This can be identified during static analysis.  It happens that in our implementation, we find this error before the expected error. 

e.g.  We process function calls by first type checking the arguments, then checking to see whether a function with the right name, arity and type of arguments exists.  In determining the type of the argument, it is apparent that the context item is not defined. 

You say "I think you should only raise a dynamic error for an expression that
contains no static errors".  Is this mandated by the specification or a personal opinion?

Well, the spec does say that you can detect dynamic errors during the static phase; but these particular errors can only be detected if you know at compile time that there will be no context item, and I don't quite see where you get that knowledge from. I don't think it's non-conformant to use such extra knowledge at compile time if it's available, but I don't think you should expect the test suite to take account of this possibility. After all, returning a different error code isn't considered to be a test failure.

I think the vast majority of the tests in the test suite that demonstrate static errors also supply no input document. If it's legitimate to return XPDY0002 for the cases you identify, then it's probably legitimate to return it for every one of these tests, which makes a nonsense of the exercise.

Perhaps there's a slightly different point here. We do have in the static context a field "Context item static type", and I suppose if the type of the context item is known in advance, then it might also be known in advance that there will be no context item, which I suppose would be represented by a static type such as "none", or by this field being null/absent. But then I would expect to see a type error of some kind, rather than a dynamic error.

Yes, we know that the context item static type is "none" because, from C.1 Static Context Components:

http://www.w3.org/TR/xquery/#id-xq-context-components

Context item static type 	none (raises error on access)

The XQTS catalog doesn't define the context item for these queries, therefore we don't overwrite this default setting.  

I think that XPDY0002 is a bit more helpful than a static typechecking error, which covers a multitude of sins.  If we throw a static type check error in this situation then we we fail about 100 more tests which expect XPDY0002 (e.g. externalcontextitem-1).

(In reply to comment #4)
> Yes, we know that the context item static type is "none" because, from C.1
> Static Context Components:
> 
> http://www.w3.org/TR/xquery/#id-xq-context-components
> 
> Context item static type        none (raises error on access)

Strictly speaking, I don't think the intent is that the default setting be the type that the FS denotes as "none" (since the XQuery doc doesn't use the FS's formal type syntax), but rather that it be "not assigned a value".

I think XPST0001 would be more appropriate than XPDY0002.

In XQuery section 2.1.2 Dynamic Context, the value of the context item is defined to be part of the dynamic context, while the static type of the context item is defined to be part of the static context in 2.1.1 Static Context.

Just to clarify, do you suggest XPST0001 because you read C.1 Static Context Components as saying that the static type of the context item is not defined?

I don't know whether this is significant, but in the table in C.1, a monospaced font is used for the word "none" for the static type of the context item.  Other items marked as "none" use a sans-serif font.  This lead me to believe that it was talking about the FS type "none".

>I don't know whether this is significant, but in the table in C.1, a monospaced font is used for the word "none" for the static type of the context item. 
Other items marked as "none" use a sans-serif font.  This lead me to believe that it was talking about the FS type "none".

Yes, and the fact that someone added "(raises error on access)" also suggests that someone was thinking this way. Of course implementations are allowed to set a different default/initial value and I strongly suspect most systems in practice have a default of item().

But we do seem to be finding quite a few areas where implementations are interpreting the spec in radically different ways. 

(In reply to comment #6)
> 
> Just to clarify, do you suggest XPST0001 because you read C.1 Static Context
> Components as saying that the static type of the context item is not defined?

Yes.

> I don't know whether this is significant, but in the table in C.1, a
> monospaced font is used for the word "none" for the static type of the
> context item.  Other items marked as "none" use a sans-serif font.
> This lead me to believe that it was talking about the FS type "none".

Huh, I hadn't noticed that. (My browser's default fonts aren't distinct enough.) 

(In reply to comment #7)
> 
> Yes, and the fact that someone added "(raises error on access)" also suggests
> that someone was thinking this way.

Actually, I think it suggests the opposite. That is, if the context item static type is undefined, then it certainly raises an error (i.e., XPST0001) if you try to access it. But if it's set to be the type that FS calls 'none', then it *is* defined, so it doesn't raise an error when you try to access that component per se, but rather when you attempt to use the type in static type analysis.

So it would be clearer if it either said
    undefined (raises XPST0001 on access)
or else
    <code>none</code> (see FS 2.4.3)
respectively.

> So it would be clearer if it either said
>    undefined (raises XPST0001 on access)
> or else
>     <code>none</code> (see FS 2.4.3)
> respectively.

Agreed.  If the latter, what exception do you suggest should be thrown?

Do you have any idea when this might be resolved one way or the other?

Would it be possible for these tests to be updated to avoid the ambiguity in the specification?

The change would only require adding <contextItem> tags to the XQTSCatalog for the problematic queries, namely:

K2-NodeTest-19, 20, 22-27
K2-NameTest-11, 35-46
K2-DirectConElemNamespace-1
K2-DirectConElemNamespace-26

The purpose of the test suite is to discover whether the specification leads to interoperable behaviour of implementations, so changing the tests when we discover that it doesn't seems an inappropriate response.

True, but it's a tad frustrating nonetheless.  Do you have an idea of the timescale by which this issue might be resolved by the working group?

Perhaps this case could be handled with a distinct set of tests.  For example, the test K2-NodeTest-10 specifically states the purpose of the test as "There is no type by name document()."  Perhaps another test could be created for "Context item referenced when the static type of the context item is 'none'".

My apologies for the late followup.

Implementations are allowed to raise dynamic errors at compile time if they can infer that the error allways is raised at runtime. However, concluding/inferring that for instance K2-NodeTest-25:

document-node(schema-element(notBound:ncname))

will raise XPDY0002 at runtime, does not hold since the query cannot be run at all, as I see it. "A dynamic error is an error that must be detected during the dynamic evaluation phase and may be detected during the static analysis phase." The dynamic error can never occur since the query cannot be evaluated, and hence there's no dynamic error to detect at compile.

The conclusion of this is that a dynamic error can never be raised, not even at compile time, if the query contains a static error. Using a simple XSL-T script, it seems no test in XQTSCatalog.xml contradicts that.

How do you think this read?

(I can easily sympathize with the implementation issues Tim describe. It feels these are word games with a low dignity. But what isn't, when it comes to spec details.)

But remember that the default of "none" for the context item static type is only a default, implementations are allowed to use a different value, for example "item()". In fact, it's not really clear whether the "default" means anything at all; the actual value as far as I can see is entirely implementation-defined.

OK.  I've modified our implementation.  Even if we can tell statically that a query will necessarily require the context item, if its type is known to be none we now just let it pass until the query is executed.

We now fail the following tests, so present alternative correct results.


(:*******************************************************:)
(: Test: K2-DirectConElemNamespace-13                    :)
(: Written by: Frans Englich                             :)
(: Date: 2007-07-17T17:04:38+01:00                       :)
(: Purpose: A name test whose namespace is declared with a prefixed namespace at
tribute. :)
(:*******************************************************:)
declare default function namespace "http://example.com";
<e xmlns:p="http://www.w3.org/2001/XMLSchema" a:p="{p:nametest}"/>

In addition to XPDY0002, there is use of an undefined namespace prefix "a" (XPST0081).  This also applies to K2-DirectConElemNamespace-14.

(:*******************************************************:)
(: Test: K2-LetExprWithout-17                            :)
(: Written by: Frans Englich                             :)
(: Date: 2007-07-17T17:04:39+01:00                       :)
(: Purpose: Ensure a name test is reported for using the undefined focus, when a
ppearing as a child of a let binding. :)
(:*******************************************************:)
declare function local:function()
{
    let $b := (i/a)
    return ()
};
local:function()

Here an optimizer is free to eliminate $b completely.  Therefore the empty sequence is a valid result.


(:*******************************************************:)
(: Test: K2-FunctionProlog-16                            :)
(: Written by: Frans Englich                             :)
(: Date: 2007-07-17T17:04:39+01:00                       :)
(: Purpose: A tricky parser case.                        :)
(:*******************************************************:)
declare function local:myFunction() as item()*
{***};
1

Here the function is never called.  1 is therefore a valid answer.

A fix has been attempted in CVS, XQTS_current.zip is updated.

If the resolution is satisfactory, feel free to change status to CLOSED. Otherwise, reopen this report. If no feedback is returned within two weeks, status will be changed to CLOSED. Thanks for reporting!

Thanks.