From the draft 1 mailing list:

From: Karl Czajkowski <karlcz@isi.edu>
Date: Thu Dec 12, 2002  20:08:35 Europe/London
To: ogsi-wg@gridforum.org
Subject: [ogsi-wg] find service data "links" in service data values?
Reply-To: ogsi-wg@gridforum.org

As I mentioned on the call yesterday, I think there would be value in
defining a simple link-like element to represent a remote
gsdl:FindServiceData query.  This element could appear in "partial"
service data values returned by a registry or indexing service to
signal to the client that it should issue another query for more
information, perhaps redirecting to another data source.  Any number
of such redirections could occur in one result, and redirected
results could also contain redirections.

I realize web technology already has some ways of doing this, simply
by including URIs or URLs (real links) in a result, but I would think
there is value in an OGSI-standardized expression of the remote query:

    <gsdl:findServiceDataRedirection>
        <gsdl:locator .../>
	<-- query expression -->
    </gsdl:findServiceDataRedirection>

This puts all responsibility for storing the redirection state in the
client, and is robust in terms of GSR renewal.  It is also great for
situations where you would want to direct a client to information to
which it might have priveleged access (while the index or registry
might not)---the client binds to the target service and is subject to
authorization based on its own identity.

At the same time, the client does not have to understand the query
expression, but only needs to envelope it properly to send to the
follow-up query.  The source sending the redirection element will be
doing potentially expression-language specific transformations as part
of its own query processing, e.g. path rewriting in an XQuery or XPATH
based expression.

A redirection-capable client SHOULD issue the encoded query and
"merge" the resulting service data values into the existing result,
e.g. construct the union of the new results and the containing service
data values sequence.  If the client does not understand the
redirection element, it COULD remove it and proceed with the partial
results from the initial response.

In general, I think the redirection processing would insert the
resulting <gsdl:serviceDataValues/> in place of the redirection, or
consider it an error if the enclosing type cannot hold a service data
values element at that point. But for the case where the enclosing
element is also a service data values element, I think we can define a
rewrite of:

    <gsdl:serviceDataValues>

       <gsdl:serviceData name=A/>

       <gsdl:serviceDataValues>

           <gsdl:serviceData name=B/>

       </gsdl:serviceDataValues>
    </gsdl:serviceDataValues>

to the collapsed set:

    <gsdl:serviceDataValues>

       <gsdl:serviceData name=A/>

       <gsdl:serviceData name=B/>

    </gsdl:serviceDataValues>

without loss of meaning.  There might be other reasonable rewrite
rules, but I do not think they need to be specified in OGSI unless
they affect the interpretation of results from specific operations in
the GS Spec.

I think this feature could be specified in a relatively contained way,
and I'd like to see it in the version 1 specification. Comments?


karl
 .