Lists Home |
Date Index |
From: "Eric van der Vlist" <firstname.lastname@example.org>
> On Thu, 2002-07-18 at 07:27, Rick Jelliffe wrote:
> > If I send a request for a fragment of a document,
> I think that this is where I don't understand any longer (maybe because
> of bad habits taken admnistrating web servers).
> Unless I am very wrong, in HTTP  there is no such thing as a fragment
> identifier: the client sends a HTTP request for a resource, gets this
> resource back and processes the document to find the fragment matching
> the fragment identifier.
> In other words, a client never sends a request for a fragment!
But that is not what I am talking about. HTTP is nothing to do with it.
Instead of using "fragment" I will use "chunk". And instead of "XPath 2 query"
I will use "query or locator based on the XPath2/XQuery approach" or
QOLBOTXX. So, rephrased:
If I send a request for a chunk of a document, and use some kind
of QOLBOTXX based on types, then I need to have knowledge
of the schema used.
Otherwise I cannot ask for anything by name, because the only
names I can be sure about are the ones in the actual tags. The
schema could use any names or types.
This comes down to a trust/policy issue: has the remote site/applicaiton
told me what schema is being used, and have they committed to maintaining
the names in their schemas?
So using the PSVI not only tightly couples local processes, but it
tightly couples linked processes too. In the absense of a mechanism by which
a QOLBOTXX can tell which schema was used to create the PSVI,
isn't this a bit fragile?
It seems to me that it is very desirable for a link to be able specify exactly
which PSVI it wants. Actually, I guess a "lesser" test is enough: to test
the schema that is used at the remote end can have a common notional
base with the schema at the local end (i.e. the types have the same names,
and one restricts or extends the other, in ways relevant to the query).
The big problem -- in the idea that we can link using the schema that we want
to use -- is that the other end is, in fact, probably not schema-processed PSVI
at all: it is probably a TAI interface to some non-XML data. The term
PSVI probably sets expectations a little squiffy.