I agree. I think it's reasonable for an implementation to support these types for a transitional period, and as Marc points out it is also permitted to do so under the conformance rules. So I think the tests should be removed.

Another test is: K-SeqExprInstanceOf-56, and is suggested to result in XPST0051(#3354).

*** Bug 3354 has been marked as a duplicate of this bug. ***

I don't think one can see this as a simple matter of that the test assumes an arbitrary namespace/type/prefix isn't recognized, because I think namespaces have meaning. It's not any namespace or type name, it is a namespace on the W3C domain, with a particular history, and a type-name with a particular history -- and that's what the implementation must have predefined when running the XQTS. So I think it's clear that this has only to do with XDT backwards compatibility.

There are many tests that checks unknown prefixes/types are flagged, xs:ThisTypeDoesNotExistExampleCom and similar. If the issue really was the assumption on what implementations predefines as opposed to XDT compat., all tests like that should be removed too.

I agree it is reasonable that an implementation supports the XDT types for a transitional period, but then it's no more worse than that the implementation fails those three tests during that transitional period. It is afterall only a transitional period, while the XQTS will be relevant a much longer period.

I also think the XS/XDT change is significant, because it affects interoperability. Therefore, I see a value in testing it, and pushing implementors to align with the spec.


So that's my arguments to why I want to keep the tests as is. However, I have full understanding if I sound naive(I think it is naive views). Michael, Marc, are your views still the same on this? (Removing the tests are acceptable, although not more, for me.)

Seems to me that allowing features or syntax from earlier drafts should at the least be controlled by an (implementation-defined of course) switch of some sort, and should be "off" by default, otherwise people won't ever transition.

But this is a personal reply.

Liam

> I also think the XS/XDT change is significant, because it affects
> interoperability. Therefore, I see a value in testing it, and pushing
> implementors to align with the spec.
> 

I agree that interoperability is harmed if systems have different namespaces (or different anything) in their initial static context, but if there is a desire to limit that (which I'd support, really) then surely it has to be in the spec, as
a ban on extra namespaces or at least a SHOULD NOT. Given that the spec explictly says that extra namespaces may be in scope I don't think that the test suite can fail systems that do this.
If you want to test behaviour on an unknown namespace then you can use an example.com namespace or some such (and to be really safe, allow implementers to change this to a different namespace if the namespace used is one they list
in the top of the report file as being in the initial static context).

For what it's worth, xq2xsl currently predefines xdt but it won't next time
but it does predefine xsl to the usual xslt namespace and this is likely to stay as I doubt it's possible to convert to xslt without ending up with this namespace in scope. So any tests that tested that xsl: was unbound would "fail" on xq2xsl. I don't think they should fail as the top of the report file explicitly states that xsl is bound in addition to the usual XQuery bindings.
The situation with xdt is similar.

David

I resolved this as suggested, by removing the tests, including K-SeqExprInstanceOf-56. (This was actually done some commits ago, in case the CVS log appears confusing.)

Personally, I'm not that content with the resolution since it opens the door for harmed interoperability, but it seems to be the easy, popular, and "correct" way out of it.

Feel free to change status to CLOSED if the resolution is satisfactory.


Frans