Martin:

I will follow up on this by next week.

Thanks,
Carmelo

Martin:

Correct.  Changed expected results for fn-base-uri-9 and fn-base-uri-11.
base-uri-18 was addressed by a different bug and the results were changed
as well.  Please close the bug when able to confirm.

Thanks,
Carmelo Montanez

I disagree with the change that has been made to fn-base-uri-9. The source document uses

xml:base="http:\\example.com\examples"

The XML Base specification states (section 3.1) that an XML Base processor must "encode and escape" any invalid characters in the URI to make it into a valid URI. This means that the effective base URI, after XML base processing, is http:%5C%5Cexample.com%5Cexamples, and this is what the base-uri() function should report.

Michael Kay

I also disagree with the change that has been made to base-uri-11. The XQuery specification is clear (3.7.3.3) that the document node constructor produces a document node whose base URI is taken from the static context (that is, from the base URI of the query.) There is no reason for this to be "empty".

Michael Kay

Mike/Martin:

I will bring this with the Test Task Force on Thursday and hopefully have
a final version on Friday.  Sorry I been sick last few days and unable
to follow up on things.

Carmelo

Mike: I think you're right about fn-base-uri-9, though I don't really have a clue about the xml:base spec.

Regarding fn-base-uri-11, what would be the proper version in your opinion? Spec says: "Document, element and processing-instruction nodes have a base-uri property which may be empty." The query does not declare a base-uri, so the accessor dm:base-uri() should return the empty sequence, to my understanding. My quoting of the spec was wrong though.

It's a bit environment dependent, but I would expect most systems that read the    query text from a file to allocate a static base URI based on that filename. We don't say this in so many words in the spec, but it's what base URI is all about: when a file such as an XML document, HTML document, or Query contains a relative URI, then by default it is resolved relative to the location of that file. For example if a query in c:/temp/test.xq does doc("test.xml"), I would expect it to read by default from c:/temp/test.xml. The only time this doesn't apply might be when the queries and/or source documents are in some kind of XML database.

... or in Java source code.

Actually in X-Hive you can only execute XQueries against a Document, Library or a single Node, so we always have some kind of a context URI, too. Because of that we cannot run several conformance tests that expect the context item to be empty.

I would opt not to make the tests depend on implementation defined items. I had quite a lot of issues related to time zones, various context settings, available collations etc. It just decreases the usefulness of the test suite as you get a lot more "fake" errors to check.

Mike/Martin:

I think (corect me if I am wrong) that is conceivable that fn-base-uri-11 may
return 0 or 1 depending on what the implementation does.  I think the thing to do is allow for either value.

Regarding fn-base-uri-9.  I will like to take a two step approach.  The original idea behind the test was not to have an invalid uri (my typo), so I will change the "\" to "/" and add a different test whose only pupose is to escape the
"\".  Please Close the bug if in agreement and when able to verify.

Thanks,
Carmelo

I agree.