This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The test input QName-source.xml has xmlns="QNameXSD" xmlns:ns="urn" with relatve URI rather than absolute URI for namespace names. relative URI are deprecated here and XML parsers may reject that. http://www.w3.org/2000/09/xppa As a consequence LocalNameFromQNameFunc001.xq (and other tests) have declare default element namespace"QNameXSD"; The relevant EBNF clause here is URILiteral,and 2.4.5 says However, an implementation MAY raise a static error [err:XQST0046] if the value of a URILiteral is of nonzero length and is not in the lexical space of xs:anyURI, or if it is a string that represents a "relative reference" as defined in [RFC3986]. so error XQST0046 needs to be listed as a possible outcome if the namespace is not changed to be absolute. This is in addition to the separate problem with LocalNameFromQNameFunc001.xq that the expected result can not be achieved on a system that does not support PSVI input, bug #2666. David
The following tests all use relative URI in a URILiteral term and so may potentially raise error XQST0046. Note that in some cases I think that the possibility of this error is due to an inconsistency in the xquery spec raised as bug #3485. David Queries/XQuery/OptionalFeatureErrors/CombinedErrorCodes/K-CombinedErrorCodes-2.xq "example.com/DOESNOTEXIST" Queries/XQuery/OptionalFeatureErrors/CombinedErrorCodes/K-CombinedErrorCodes-3.xq "example.com/DOESNOTEXIST" "example.com/2" "example.com/3" Queries/XQuery/OptionalFeatureErrors/CombinedErrorCodes/K-CombinedErrorCodes-4.xq "example.com/DOESNOTEXIST" "example.com/2" "example.com/3" Queries/XQuery/OptionalFeatureErrors/CombinedErrorCodes/K-CombinedErrorCodes-5.xq "example.com/DOESNOTEXIST" "example.com/2DOESNOTEXIST" "example.com/3DOESNOTEXIST" Queries/XQuery/OptionalFeatureErrors/CombinedErrorCodes/K-CombinedErrorCodes-6.xq "example.com/DOESNOTEXIST" "example.com/2DOESNOTEXIST" "example.com/3DOESNOTEXIST" Queries/XQuery/Expressions/PrologExpr/VersionProlog/version_declaration-005.xq "xspanish" Queries/XQuery/Expressions/PrologExpr/VersionProlog/prolog-version-8.xq "xspanish" "comment.xsd" Queries/XQuery/Expressions/PrologExpr/VersionProlog/K-VersionProlog-5.xq "example.com/" "example.com/a/Namespace" "example.com/" "example.com/" Queries/XQuery/Expressions/PrologExpr/CollationProlog/K-CollationProlog-1.xq "collation/codepoint" Queries/XQuery/Expressions/PrologExpr/CollationProlog/K-CollationProlog-2.xq "collation/codepoint/DOESNOTEXIT/Testing" Queries/XQuery/Expressions/PrologExpr/BaseURIProlog/base-URI-2.xq "abc<" Queries/XQuery/Expressions/PrologExpr/BaseURIProlog/base-URI-3.xq "abc>" Queries/XQuery/Expressions/PrologExpr/BaseURIProlog/base-URI-4.xq "abc&" Queries/XQuery/Expressions/PrologExpr/BaseURIProlog/base-URI-5.xq "abc"" Queries/XQuery/Expressions/PrologExpr/BaseURIProlog/base-URI-6.xq "abc'" Queries/XQuery/Expressions/PrologExpr/BaseURIProlog/base-URI-11.xq "abc123" Queries/XQuery/Expressions/PrologExpr/BaseURIProlog/base-URI-12.xq "abc""" Queries/XQuery/Expressions/PrologExpr/BaseURIProlog/base-URI-13.xq 'abc''' Queries/XQuery/Expressions/PrologExpr/BaseURIProlog/base-URI-14.xq 'abc##0;' Queries/XQuery/Expressions/PrologExpr/BaseURIProlog/base-URI-15.xq "A" Queries/XQuery/Expressions/PrologExpr/BaseURIProlog/base-URI-16.xq "" Queries/XQuery/Expressions/PrologExpr/BaseURIProlog/base-URI-17.xq "/" Queries/XQuery/Expressions/PrologExpr/BaseURIProlog/base-URI-18.xq "abc 
" Queries/XQuery/Expressions/PrologExpr/BaseURIProlog/base-URI-19.xq "declare base-uri" Queries/XQuery/Expressions/PrologExpr/BaseURIProlog/base-URI-20.xq "base-uri" Queries/XQuery/Expressions/PrologExpr/BaseURIProlog/base-URI-21.xq "base-uri" Queries/XQuery/Expressions/PrologExpr/BaseURIProlog/base-URI-22.xq " http://www.example.org/examples" Queries/XQuery/Expressions/PrologExpr/NamespaceProlog/K2-NamespaceProlog-1.xq "" Queries/XQuery/Expressions/PrologExpr/NamespaceProlog/K2-NamespaceProlog-2.xq "" Queries/XQuery/Expressions/PrologExpr/NamespaceProlog/K2-NamespaceProlog-3.xq "" Queries/XQuery/Expressions/PrologExpr/NamespaceProlog/K2-NamespaceProlog-4.xq "" Queries/XQuery/Expressions/PrologExpr/NamespaceProlog/K2-NamespaceProlog-5.xq "" Queries/XQuery/Expressions/PrologExpr/NamespaceProlog/K2-NamespaceProlog-6.xq "" Queries/XQuery/Expressions/PrologExpr/NamespaceProlog/K2-NamespaceProlog-7.xq "" Queries/XQuery/Expressions/PrologExpr/FunctionDeclaration/function-declaration-025.xq "" Queries/XQuery/Expressions/ExtensionExpression/K-ExtensionExpression-5.xq "" Queries/XQuery/Expressions/ExtensionExpression/K2-ExtensionExpression-1.xq "" Queries/XQuery/Functions/AccessorFunc/StaticBaseURIFunc/fn-static-base-uri-5.xq " telnet://192.0.2.16:80/" Queries/XQuery/Functions/QNameFunc/LocalNameFromQnameFunc/LocalNameFromQNameFunc001.xq "QNameXSD" Queries/XQuery/Functions/QNameFunc/LocalNameFromQnameFunc/LocalNameFromQNameFunc002.xq "QNameXSD" Queries/XQuery/Functions/QNameFunc/LocalNameFromQnameFunc/LocalNameFromQNameFunc003.xq "QNameXSD" Queries/XQuery/Functions/QNameFunc/LocalNameFromQnameFunc/LocalNameFromQNameFunc004.xq "QNameXSD" Queries/XQuery/Functions/QNameFunc/LocalNameFromQnameFunc/LocalNameFromQNameFunc005.xq "QNameXSD" Queries/XQuery/Functions/QNameFunc/LocalNameFromQnameFunc/LocalNameFromQNameFunc010.xq "QNameXSD" Queries/XQuery/Functions/QNameFunc/LocalNameFromQnameFunc/LocalNameFromQNameFunc012.xq "QNameXSD" Queries/XQuery/Functions/QNameFunc/LocalNameFromQnameFunc/LocalNameFromQNameFunc013.xq "QNameXSD" Queries/XQuery/Functions/QNameFunc/LocalNameFromQnameFunc/LocalNameFromQNameFunc014.xq "QNameXSD" Queries/XQuery/Functions/QNameFunc/LocalNameFromQnameFunc/LocalNameFromQNameFunc018.xq "QNameXSD" Queries/XQuery/Functions/QNameFunc/LocalNameFromQnameFunc/LocalNameFromQNameFunc019.xq "QNameXSD" Queries/XQuery/Functions/QNameFunc/LocalNameFromQnameFunc/LocalNameFromQNameFunc020.xq "QNameXSD" Queries/XQuery/Functions/QNameFunc/LocalNameFromQnameFunc/LocalNameFromQNameFunc021.xq "QNameXSD" Queries/XQuery/Functions/QNameFunc/NamespaceURIFromQNameFunc/NamespaceURIFromQNameFunc001.xq "QNameXSD" Queries/XQuery/Functions/QNameFunc/NamespaceURIFromQNameFunc/NamespaceURIFromQNameFunc002.xq "QNameXSD" Queries/XQuery/Functions/QNameFunc/NamespaceURIFromQNameFunc/NamespaceURIFromQNameFunc003.xq "QNameXSD" Queries/XQuery/Functions/QNameFunc/NamespaceURIFromQNameFunc/NamespaceURIFromQNameFunc004.xq "QNameXSD" Queries/XQuery/Functions/QNameFunc/NamespaceURIFromQNameFunc/NamespaceURIFromQNameFunc005.xq "QNameXSD" Queries/XQuery/Functions/QNameFunc/NamespaceURIFromQNameFunc/NamespaceURIFromQNameFunc010.xq "QNameXSD" Queries/XQuery/Functions/QNameFunc/NamespaceURIFromQNameFunc/NamespaceURIFromQNameFunc012.xq "QNameXSD" Queries/XQuery/Functions/QNameFunc/NamespaceURIFromQNameFunc/NamespaceURIFromQNameFunc013.xq "QNameXSD" Queries/XQuery/Functions/QNameFunc/NamespaceURIFromQNameFunc/NamespaceURIFromQNameFunc014.xq "QNameXSD" Queries/XQuery/Functions/QNameFunc/NamespaceURIFromQNameFunc/NamespaceURIFromQNameFunc018.xq "QNameXSD" Queries/XQuery/Functions/QNameFunc/NamespaceURIFromQNameFunc/NamespaceURIFromQNameFunc019.xq "QNameXSD" Queries/XQuery/Functions/QNameFunc/NamespaceURIFromQNameFunc/NamespaceURIFromQNameFunc020.xq "QNameXSD" Queries/XQuery/Functions/QNameFunc/NamespaceURIFromQNameFunc/NamespaceURIFromQNameFunc021.xq "QNameXSD" Queries/XQuery/SchemaImport/SchemaImportProlog/schema-import-3.xq "" Queries/XQuery/Modules/ModuleImport/modules-none.xq "empty-lib.xq" Queries/XQuery/Modules/ModuleImport/modules-emptyns.xq "" Queries/XQuery/Optional/Modules/ModuleImport/K-ModuleImport-1.xq "" Queries/XQuery/Optional/Modules/ModuleImport/K-ModuleImport-2.xq "" "example.com/" "example.com/2"
(In reply to comment #1) > The following tests all use relative URI in a URILiteral term and so may > potentially raise error XQST0046. Note that in some cases I think that the > possibility of this error is due to an inconsistency in the xquery spec > raised as bug #3485. > > David Just to clarify, I think that use of a relative URI as a namespace ought to be avoided in the test suite so those tests should be changed irrespective of the outcome of bug #3485. It might not be possible to run the tests at all if an xml parser rejects the input as being not namespace well formed. The tests that use relative URI as location hints for Module and Schema import hopefully will not need changing if the outcome of #3485 confirms that this is not an error. It would be very odd if references to query modules may not be relative to the base URI of the current module. so for example K-ModuleImport-2.xq "" "example.com/" "example.com/2" should I think be unchanged even though listed in comment #1. Note however the relative URI example.com/2 may be a bit misleading to a human reader, being a reference (typically) to a file in the example.com subdirectory of the current directory, rather than to a file served on a site in the DNS domain example.com, so perhaps there may be a wish to change this to the absolute "http://www.example.com/2" (or relative "some/directory/2") for different reasons. David
(This post might seem a bit ignorant to the comments and other reports posted. I wrote down/implemented this before other comments dropped in.) I think the URI in 'declare default collation' can be relative, because "4.4 Default Collation Declaration" reads: "If a default collation declaration specifies a collation by a relative URI, that relative URI is resolved to an absolute URI using the base URI in the static context." Among the K-* tests, this render K-CollationProlog-1 and K-CollationProlog-2 as being in order, and needs no fixing, as I see it. All "K2-NamespaceProlog-*" tests, K2-ExtensionExpression-1 and K2-ExtensionExpression-1 specify zero-length namespace URIs, "". I believe this is valid. Section "4.12 Namespace Declaration" reads: "If the URILiteral part of a namespace declaration is a zero-length string, any existing namespace binding for the given prefix is removed from the statically known namespaces." For that reason, I believe K2-NamespaceProlog-* are correct as is, and needs no fixing. K-ModuleImport-1 and K-ModuleImport-2 also specify zero-length namespaces, but also expect XQST0088. Section "4.11 Module Import" reads: "The first URILiteral in a module import must be of nonzero length [err:XQST0088]." Therefore, no fix needed, I think. However, K-ModuleImport-2 had relative location hints, which was fixed. Hence, this is what my notes looks like. "DONE" means a tests was edited, while "DONE NOFIX" means it was left untouched: DONE K-CombinedErrorCodes-2 DONE K-CombinedErrorCodes-3 DONE K-CombinedErrorCodes-4 DONE K-CombinedErrorCodes-5 DONE K-CombinedErrorCodes-6 DONE K-VersionProlog-5 DONE NOFIX K-CollationProlog-1 DONE NOFIX K-CollationProlog-2 DONE NOFIX K2-NamespaceProlog-1 DONE NOFIX K2-NamespaceProlog-2 DONE NOFIX K2-NamespaceProlog-3 DONE NOFIX K2-NamespaceProlog-4 DONE NOFIX K2-NamespaceProlog-5 DONE NOFIX K2-NamespaceProlog-6 DONE NOFIX K2-NamespaceProlog-7 DONE NOFIX K-ExtensionExpression-5 DONE NOFIX K2-ExtensionExpression-1 DONE NOFIX K-ModuleImport-1 DONE K-ModuleImport-2 In other words, I see #3485 for the purposes of this report as an editorial issue, and that it is intentional that things like resolving the collation URI is intended to override the general clause about the URILiteral EBNF product. Whether URIs for location hints in module/schema imports will changed to require being resolved if relative doesn't affect these K-* tests. I've committed the frans-submission*.zip files, and XQTS_current.zip is updated. I think the other tests remains now. I haven't looked at them, but probably the analysis in this comment applies to some of them. Nice that you reported this David. How did you find the tests? Frans
> I think the URI in 'declare default collation' can be relative, because "4.4 > Default Collation Declaration" reads: yes although the xquery spec currently has it backwards (I claim). The parser is given licence to abort the run by the EBNF comment so the process may never get as far as looking at the higher level processing specified here for collations. However the behaviour for relative collations is defined, and obviously relative links to modules and schema should be allowed, so I hope that it's essentially just an editorial change required to the xquery spec, and that it's only the cases involving relative namespaces that should affect the test suite. > Nice that you reported this David. How did you find the tests? used XQuery of course! (Well actually XSLT, but it's the same thing:-) xq2xml offers an XML view of the Query text, then something like <xsl:template match= "Module[.//URILiteral[not(matches(data,'^[''"][a-zA-Z]+:'))]"> <xsl:message> <xsl:value-of select="base-uri(), .//URILiteral[not(matches(data,'^[''"][a-zA-Z]+:'))]"/> </xsl:message>
To fix bug 3447: change relative URI "QNameXSD" to "http://www.example.com/QNameXSD" change relative URI "urn" to "http://www.example.com/urn"
This bug has been marked as resolved but I'm reopening as there are still several tests using relative URI terms, including for example base-URI-15 which declares a base URI of "A", as listed in comment #1. base-URI-15 for example currently has an expected result of "A" I generate "file:/C:/cygwin/2006/xq2xml/Queries/XQuery/Expressions/PrologExpr/BaseURIProlog/A" which I believe should be the correct (on this machine) answer for this query, depending on the outcome of bug #3485. I think this bug should be left open until 3485 is resolved.
> I think this bug should be left open until 3485 is resolved. Also (more specifically) bug #3486
Note that the WG proposal for resolving bug #3486 http://www.w3.org/Bugs/Public/show_bug.cgi?id=3486#c3 would invalidate the expected result files of most of the base URI tests in the test suite. It would confirm for example that the currently specified result of base-URI-15 is incorrect and the result specified in comment #6 is correct. Since this result is highly system dependent I would suggest changing all the affected files (see the list in comment #1) to have an explict absolute base URI in the static context specified by either changing the current declaration to use an absolute URI, or adding a declaration specifying an absolute URI for tests that do not have such a declaration. It would be good if this could be done for XQTS 1.0 as handling of relative URI literals accounts for almost a quarter of my "failures" on the test suite so the outcome of this bug report is completely skewing the test results. David
Folks: Sorry was not aware that some of my tests were part of this bug. I will work on my tests, but not sure you will any changes for XQTS 1.00 as release is due soon. I do not see what is the problem with "Base-URI-22.xq". Thanks, Carmelo
More on this still: Regarding - schema-import-3 - The purpose of the test is to raise "XQST0057" according to teh following section from the Query specs "A schema import that specifies a zero-length string as target namespace is considered to import a schema that has no target namespace. Such a schema import may not bind a namespace prefix [err:XQST0057] ..." Regarding "modules-none" - The purpose of the test is to import a non existent module and raise the appropriate error as per the following section of the Query specs: "It is a static error [err:XQST0059] if the implementation is not able to process a module import by finding a valid module definition with the specified target namespace ..." Regarding modules-emptyns - Even though the description is a bit vague (which I will correct), the purpose is to raise XQST0088 as per the following section of the query specs ... "The first URILiteral in a module import must be of nonzero length [err:XQST0088], and specifies the target namespace of the modules to be imported. ...." Regarding Base-URI-16 and Base-URI-17, I am struggling a bit with those, any hints will be appreciated. Thanks, Carmelo
(In reply to comment #10) > Regarding Base-URI-16 and Base-URI-17, I am struggling a bit with those, any > hints will be appreciated. > -16 has a base-uri specified of "". The relevant EBNF production here is URILiteral and as discussed over in bug #3485 the XQuery spec is currently inconsistent in whether that is allowed, or if it is allowed, what it means. Assuming the resolution is that it is allowed, an empty URI reference should be a document self-reference. But in any case this test probably needs to wait for the resolution of 3485. -17 has similar issues as to whether it's allowed to specify the non-absolute uri in the input syntax, but in this case there is the additional problem that (assuming the input is not a syntax error) the expected result file is wrong. It expects "/" but the base URI is defined to be an _absolute_ URI so can not be / the assumption (and the suggested resolution in bug #3485) is that a relative URI should be resolved against the existing static base uri, which in the case of reading the query from the file system results in a value something like "file:/" This same comment applies to many of this series eg -11 has expected result abc123 but again base-uri must always return an absolute URI so this can not be right, xq2xsl returns file:/C:/cygwin/2006/xq2xml/Queries/XQueryXSLT/Expressions/PrologExpr/BaseURIProlog/abc123 on this system which I believe is the correct result. In order to avoid such system dependencies as the exact file path on which i happen to run the query, the tests should use absolute URI. > I do not see what is the problem with "Base-URI-22.xq". There is nothing wrong with it, sorry. The list in comment #1 is all the uses of URI literal where the value is not an absolute URI, but in the regex I used to test for absolute uri I forgot to ignore leading white space looking down the list it seems that this is the only one that is mis-reported in this way.
(In reply to comment #11) I wrote > In order to avoid such > system dependencies as the exact file path on which i happen to run the query, > the tests should use absolute URI. Or of course just use an expression that is not so sensitive to the local context for example use ends-with(.....,'abc123') and have the expected result of true
All: I fixed the remaining tests in question to use abosulte base-uri properties. Tests base-URI-16 and 17 and just invalid tests. They were removed. Thanks, Carmelo
Thanks, will XQTS_current.zip be updated in cvs as changes are made, I'd rather run against that than build a test suite using the ant build as that's one less thing to go wrong and introduce spurious differences. (An even better alternative would be if the "Additional zip files" were unpacked and the individual tests and full catalog added to CVS directly.) If the outcome of bug #3486 is that the XQuery spec clarifies that it is legal to use the syntax of a relative base uri in the base uri declaration, with the effect that the base uri in the static context is the absolute uri obtained by resolving the specified relative uuri against the existing base, then XQTS should keep at least one test which uses declare base-uri with a relative URI, and tests thet base-uri() returns a suitable absolute URI in that case. David
All: Just a quick note to indicate that a new test was added to evaluate usage of a relative URI for declaration of base-uri property. Thanks, Carmelo