3485 2006-07-18 21:03:15 +0000 [XQuery] relative URILiteral 2007-02-25 23:50:46 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XQuery 1.0 Candidate Recommendation PC Windows XP CLOSED FIXED P2 normal --- 1 davidc chamberl public-qt-comments oldest_to_newest 10580 0 davidc 2006-07-18 21:03:15 +0000 The XQuery spec seems to be inconsistemt on whether URILiteral terms may be relative. The clause is defined in section 2.4.5 which says However, an implementation MAY raise a static error [err:XQST0046] ... or if it is a string that represents a "relative reference" as defined in [RFC3986]. So it would appear that a relative URI is an error that may be reported as XQST0046, however at least two places where URILiteral terms are used give explict non-error behaviour for relative URI. 3.8.3 If an orderspec specifies a collation by a relative URI, that relative URI is resolved to an absolute URI using the base URI in the static context. 4.4 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. Perhaps 2.4.5 should be ammended to say that XQST0046 may be raised (just) if the URI Literal is not an absolute URI after resolving (if necessary) against the base URI in the static context. Note this affects several test suite tests, see bug #3447 David 10645 1 frans.englich 2006-07-21 22:16:50 +0000 As I see it, URILiterals are used in two different ways: referring to namespaces and as resource(file) references. Applying resolution of relative URILiterals is invasive(at this stage) because it affects much. It perhaps neither makes sense for namespaces. One could also question if resolving against the static base URI makes sense for all URILiteral scenarios. Replying comment #2 in #3447: Relative URIs in location hints in schema imports and and module imports can be valid, because both their sections reads: "The URILiterals that follow the at keyword are optional location hints, and can be interpreted or disregarded in an implementation-dependent way." I think this should be changed to that they are resolved against the static base URI, because: 1) it's what users expects(it's common behavior; xml:base/XInclude to mention XML examples), 2) it is what typically is implemented, is my guess; and 3) it affects interoperability. Location hints in the mentioned declaration imports aren't interoperable for even the most basic schemes(such as http:// and file://, which are rather common). However, there's perhaps a conscious reason to why not even relative URI-resolving have been specified. Proposed fix: In 4.10 Schema Import and 4.11 Module Import replace: "The URILiterals that follow the at keyword are optional location hints, and can be interpreted or disregarded in an implementation-dependent way." with: "The URILiterals that follow the at keyword are optional location hints which are resolved against the base URI if being relative URIs, but beyond that are interpreted or disregarded in an implementation-dependent way." I think it would solve one of David's interests in resolving URILiterals. That "2.4.5 URI Literals" clashes with sections that more specifically describes the URILiteral, can perhaps be solved with this proposed change: In "2.4.5 URI Literals", replace: '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].' with: '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. An implementation MAY also raise a static error [err:XQST0046] if it is a string that represents a "relative reference" as defined in [RFC3986], unless any section that specifically applies to the URILiteral in question specifies how a "relative reference" is handled.' That is, it allows other sections to "override" the more general one in "2.4.5 URI Literals" which currently is intended(I think). It's not very clean(e.g, it's an exception), but perhaps it is /better/ and the best approach available at this stage. Frans 11125 2 mike 2006-08-15 16:05:23 +0000 Note also a typo in section 2.4.5: $#xA; should read &#xA; 11185 3 chamberl 2006-08-16 23:11:36 +0000 I have corrected the typo identified in Comment #2. Thanks, Mike! Since this bug report has a larger scope, I am leaving it open. --Don Chamberlin 11633 4 chamberl 2006-09-12 23:00:06 +0000 David, In a meeting on Aug. 25, 2006, the Query Working Group decided that the definition of a URILiteral should be changed to allow a relative URI. XQuery section 2.4.5 and error message XQST0046 have been edited accordingly. The working group believes that this change resolves the issue raised by this bug report. If you agree, please change the status of this report to "Closed". Regards, Don Chamberlin (for the Query Working Group) 11634 5 davidc 2006-09-12 23:22:18 +0000 I'm happy with the resolution that syntactically a relative uri literal should not be an error, but your message doesn't say what the non error meaning should be, this isn't clear in all cases. As noted in comment 0, the behaviour of relative collation URI are already specified (resolve against the base uri in the static context) This should also probably be the behaviour in other cases (eg module and schema import) However in namespace declarations relative URI should probably still be an error (although you may want to make it just optional that the error is reported which is probably the original reason for the current text in 2.4.5) w3c policy being that relative namespace uri are evil and specs should not assign meaning to them) specifying a relative base uri (using the prolog declaration or xml:base) is another tricky case that has its own entry, bug #3486 David 11649 6 davidc 2006-09-13 12:51:17 +0000 I see you've responded to bug #3486, so I think that means that the only case that would be left undefined would be namespace uri Could the specification clarify whether the following is in error, and if not in error, what the namespaces of the elements x and y are? to be specific: declare base-uri "data:,x"; declare default element namespace "abc/123"; <x> <y xmlns="xyz"/> </x> Currently saxon gives no error and produces <?xml version="1.0" encoding="UTF-8"?> <x xmlns="abc/123"> <y xmlns="xyz"/> </x> I wouldn't object to that being the specified behaviour although acording to a w3c directive that "revised" the interpretation of the namespaces spec, such an xml document has undefined behaviour and shouldn't be assigned definite semantics, so XQuery might want to make relative uri namespaces explictly an error, or undefined, and may want to state explictly that they are _not_ resolved against the base uri in the static context (unlike all other uses of uriliteral) http://lists.w3.org/Archives/Public/xml-uri/2000Sep/0083.html and namespaces 1.1 which rather commits xpath2 (at least) to not doing much with relative uri namespace literals. http://www.w3.org/TR/REC-xml-names/#iri-use This deprecation of relative URI references was decided on by a W3C XML Plenary Ballot Relative URI deprecation]. It also declares that "later specifications such as DOM, XPath, etc. will define no interpretation for them". David 14163 7 jim.melton 2007-02-25 23:50:46 +0000 Closing bug because commenter has not objected to the resolution posted and more than two weeks have passed.