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

Note also a typo in section 2.4.5:

$#xA;

should read




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

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)

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

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

Closing bug because commenter has not objected to the resolution posted and more than two weeks have passed.