Mike Rorke is marked as the author of these tests.

Also, the schema URIs seems to need fixing since they are relative while they should be absolute. See #3447(perhaps that's the one Alberto refers to).

All:

Perhaps te fix here is not the Import Sche itself, because if there
is no validation of the data, you are still in an error condition.

Perhaps the thing to do is to build the QName on the fly with 

string Cast as QName expression.

Carmelo

(In reply to comment #2)
> All:
> 
> Perhaps te fix here is not the Import Sche itself, because if there
> is no validation of the data, you are still in an error condition.
> 
> Perhaps the thing to do is to build the QName on the fly with 
> 
> string Cast as QName expression.
> 
> Carmelo

Well we've been asking since the first public versions of the test suite
for tests requiring typed nodes to construct the nodes within the Query
rather than depend on PSVI input see for example bug #1997. If finally that's going to be done, that would be good, or failing that tests requiring PSVI input should be moved to an optional area of the test suite for systems that support that feature. You are correct though that the test files do not need (and should not have) a schema import declaration.
 

David

The tests in the first list have already been moved to an optional area of the test suit, Optional -> SchemaImport; they just miss the "import schema" statement that makes the data of the type expected

(In reply to comment #4)
> The tests in the first list have already been moved to an optional area of the
> test suit, Optional -> SchemaImport; they just miss the "import schema"
> statement that makes the data of the type expected
> 

I don't believe that a schema import would have any effect on the queries.
they do not use any type or element declarations within the query text.
They do need the input document to be schema validated and the initial tree constructed from a PSVI but that is a system-specific feature not controlable from XQuery.

David

I agree that the query doesn't use user-defined types; but the input document doesn't refer to a schema, and the XQTS instruction doesn't say that an input XML should be schema validated only because there is a schema available for the namespace that the query or the XML happen to use.
And, even in that case, I guess that schema validating every input XML will break all those queries that expect untyped data.
So, in my opinion, the easiest way to have PSVI-validated data starting from an XML that doesn't point to a schema is by loading the schema from within the query.

(In reply to comment #6)
> I agree that the query doesn't use user-defined types; but the input document
> doesn't refer to a schema, 

Oh that's probably a bug it used to refer to a schema didn't it?

> and the XQTS instruction doesn't say that an input
> XML should be schema validated only because there is a schema available for the
> namespace that the query or the XML happen to use.

no, but it _could_ say that.

> And, even in that case, I guess that schema validating every input XML will
> break all those queries that expect untyped data.
> So, in my opinion, the easiest way to have PSVI-validated data starting from an
> XML that doesn't point to a schema is by loading the schema from within the
> query.

Nothing in the XQuery spec suggests that using a schema import declaration should affect the building of input trees, and these tests can be passed by systems that support building trees from PSVI but do not support Schema Import. (It's not unlikely that such systems could exist, even if the initially available XQuery implementations do not support that, as input from a PSVI just needs an API to build a tree from a 3rd party validating XML parser whereas schema import requires much tighter integration of XSD support into the Query engine.

David,
I am not in the XQTS team, so I don't know what you decided when you wrote these queries; but, as it stands now, this query cannot run successfully without an arbitrary modification.
To recap the possible choices:

1) atomic.xml gets an xsi:namespaceLocation="http://www.w3.org/XQueryTest atomic.xsd" attribute
2) the query gets an "import schema" statement
3) the guidelines gets a comment about "whenever a namespace is defined in a query, the corresponding schema need to be loaded" (but currently is say the opposite: in the "Customizing Namespaces" it says that implementors are allowed to take an "import schema" and replace it with a "declare namespace")

Now, the test is placed under the Optional group of test, under a group named "SchemaImport". This makes me think that the query should be fixed according to option #2 (i.e. add an "import schema" statement), otherwise they should be in the "MinimalConformance" group, isn't it? So why are you trying to make this query run without schema import?

Alberto

> I am not in the XQTS team, so I don't know what you decided when you wrote
Oh sorry ,I should have said explictly, neither am I, I'm not in the working Groups at all.

However the recent changes to these tests were at least partly triggered by some bug reports that I sent in (asking that the schema dependence be removed or made explict in the catalog) so I felt I could offer some background as to how they came to be as they are.


The test should not be in minimal conformance as conforming implementations (including my own, saxonB and several other existing ones) conform to that level but can not input typed data so should not be made to fail the test.

I asked that they be moved to a separate area of the test suite for "PSVI input" actually they have been mved to "schema import" which isn't so accurate but probably workable.

Of your three solutions, I think (1) should be chosen and the xml file once again reference the schema. I do not believe (2) is a solution at all. A query engine that does schema import may (and probably should) still input an untyped tree if the schema import is added to the query as the schema import statement should have no effect on input trees. On (3) if it were to be fixed in the catalog I think the way it should be done is for the <input-file> to have an attribute saying to schema validate using atomic.xsd, however as I say I think (1) is best.

Currently (in cvs) atomic.xml declares
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
but never uses the xsi namespace. I think that is just a bug and it should have
an xsi:schemaLocation pointing to atomic.xsd

David

Also applies to ForExprType010

I've just done a quick review of this report, and I believe that these test cases need to operate on QNames that have been constructed in the query.

We decided some time ago that we needed to either 1) provide expected results for implementations that validate their input documents and for implementations that do not do so, or 2) construct typed values in the query  (see http://www.w3.org/Bugs/Public/show_bug.cgi?id=1997#c13).

Changed the queries to force the type to be xs:QName as an argument to the functions.  
Move the specified two tests to optional feature area

Using XQTS_current v. 1.37

Hi Funda,
there are a bunch of typos in the tests

- LocalNameFromQNameFunc005, NamespaceURIFromQNameFunc001 and NamespaceURIFromQNameFunc005 use xs:String instead of xs:string
- NamespaceURIFromQNameFunc002, NamespaceURIFromQNameFunc004, NamespaceURIFromQNameFunc018, NamespaceURIFromQNameFunc019 and NamespaceURIFromQNameFunc020 construct a QName using the namespace http://www.example.com/QNameXSD but then they expect http://www.example.com/urn as the result
- NamespaceURIFromQNameFunc003 is missing the fn:QName around the two arguments of the namespace-uri-from-QName function
 

Fixed the issues and Carmelo verified that the tests work with no errors.

There still seems to be an error in LocalNameFromQNameFunc018: it calls

fn:QName("http://www.example.com/QNameXSD", data((/root/elemQN)[1]))

where the second argument of fn:QName is of type xs:QName - this is a type error.

Also, please note, I have raised bug #3606 on the spec concerning the need for a separator in 

declare namespace"xyz";

The spec currently appears to require a space here, though my parser accepts this declaration as written.

All:

Its looks as though, all tests here been changed accordingly.  I will mark this bug as fixed.  Please feel free to push back if you think otherwise.

Thanks,
Carmelo