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

[Bug 1998] Inconsistency wrt module import new text

From: <bugzilla@wiggum.w3.org>
Date: Tue, 28 Feb 2006 16:25:02 +0000
To: public-qt-comments@w3.org
Message-Id: <E1FE7eo-0001Rb-IA@wiggum.w3.org>


------- Additional Comments From holstege@mathling.com  2006-02-28 16:26 -------

The WG considers this issue closed and intends to make no change in this
area.  If you not satisfied with this resolution, please let us know.

In answer to your question: The fact is that there is much that is 
implementation defined in this area, starting with the basic point that
the entire module feature is optional. Further, URI resolution is implementation
defined as well.  So, even if the spec were to insist that location URIs
were more than hints and they must be obeyed, there is no guarantee that
the URI resolver in two implementations would work as expected.  

It it not reasonable to expect to be able to pick up a large application (i.e. 
one dependent on modules) from one implementation and drop it down on another
and expect it to work with no knowledge of the implementation. This goes far 
beyond modules:
There are plenty of other implementation-dependent/defined features in the
XQuery language that can dramatically affect how or whether applications
will work, e.g. static typing, URI resolution wrt fn:doc, locating schemas and
whether to apply them at all.

I don't believe, for modules, this is different in kind from what you find in 
other programming languages, although it certainly differs in degree.
The C _language spec_ does not tell you what you get when you put 
#include "foo.h" into your program or where it will be located: your compiler 
documentation does. 

Speaking only for myself, I would have preferred a design that made locations
more than just hints, but given the range of contexts in which XQuery 
implementations are living -- as self-embedded application languages
working off file systems or off their own internal stores, as queries embedded
in the context of SQL engines, as transformation engines inside application
servers, and others besides -- it is difficult to come up with hard and
fast rules that won't make certain reasonable implementation choices impossible.
The price application developers have to pay for this is the possibility of
having to modify applications to work in certain implementation contexts.
The current design has the virtue of making reasonable implementations possible.
Received on Tuesday, 28 February 2006 16:25:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:10 UTC