W3C home > Mailing lists > Public > public-qt-comments@w3.org > July 2006

[Bug 3485] [XQuery] relative URILiteral

From: <bugzilla@wiggum.w3.org>
Date: Fri, 21 Jul 2006 22:16:51 +0000
CC:
To: public-qt-comments@w3.org
Message-Id: <E1G43Ih-0006RH-0h@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=3485





------- Comment #1 from frans.englich@telia.com  2006-07-21 22:16 -------
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
Received on Friday, 21 July 2006 22:17:03 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:29 UTC