This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This test: for $book in $input-context/books/book let $cont := $book//content where $cont contains text "program" using thesaurus at "http://bstore1.example.com/TechnicalThesaurus.xml" relationship "UF" return $book has the thesaurus URI resolve to an intentionally missing thesaurus XML file and an expected result of error of FTST0018: It is a static error if, during the static analysis phase, the query is found to contain a thesaurus option that refers to a thesaurus that is not found in the statically known thesauri. IMHO, there's a difference between "known" and "missing". Suppose, for a different query that makes use of the UsabilityThesaurus.xml (which resolves to usability.xml), I accidentally delete the usability.xml file. The URI resolution is just the same as before in that it will correctly resolve to the usability.xml file (hence, the referred-to thesaurus URI is just as "known" as it was before), it's just that the file doesn't exist. An XQuery implementation should give some kind of "file not found" error that's a lot more specific. It's a lot more helpful to distinguish the two cases especially if you were some poor person whose pager went off at 3am because a running XQuery server emitted an error. It would be a lot more helpful have said person look immediately for a missing file rather than having to check to see it the URI resolution is correct. It's a "quality of implementation" issue. If you really want this test to have an expected result of FTST0018, then the catalog should have *no* mapping at all for TechnicalThesaurus.xml -- then it wouldn't be "known". The severity on this bug is higher than normal for those of us who have automated test suites and who want to pass all the tests.
(For myself) I don't think a distinct error code is warranted. I think the analogy with how collation URIs are handled is a good one. While in theory one could take the URI as a literal reference to some resource that gets dereferenced at query time, in most implementations it is taken as a name that references a precompiled efficient data structure or code module. I can see that if an implementation does choose to dereference it as a live URI, then you may want to report somewhat different information to the end-user, but that is not the same as saying the error code in the spec has to be different. The fact is, for most implementations, the distinction you want to make is meaningless and untestable.
Even if I think that everything you've just said were correct, you could still get the same effect by simply not including a URI mapping in the XQFTTS catalog file. Then the URI would truly be unknown. That's all I want, not a change to the spec, i.e., I am not suggesting that a new error code be created. If the mapping were not there, then I could easily return FTST0018. However, for my implementation (as a "quality of implementation" improvement), I'd be free to return some other "file not found" error when the mapping is there but the mapped-to resource is not. So if you simply remove the mapping from the XQFTTS catalog file, I think everybody would be happy.
The WG discussed this bug in the meeting of 2011-02-08. While we agree that the metadata in the catalog could be improved (something we will look to in XQuery FT 3.0), we decided not to change it right now. In addition, since some implementations find the suggested strategy (not mentioning the binding at all) more troublesome than the current strategy (mentioning the binding, but referring to an absent file), simply altering strategies did not look like a good idea to us. However, we have clarified the instructions to indicate that in the context of the test suite, a binding to an absent file is to be taken as indicating a missing binding, and a test harness should provide whatever initialization is required on the basis of this information. Please indicate your satisfaction with this resolution by closing the bug.