Re: ERB call on addressing

>> ... Here, you are actually asking for a standard
>>tree query and transformation language to be supported by
>>all servers.
> 
>This view seems to come up frequently (sometimes in the formulation
>"server owners think the syntax of the query segment belongs to
>them, so we can't specify it"), and it makes no sense to me, so let
>me ask the dumb question.  What do you mean?

Note that I have *never* said that I think the *query* segment belongs
to the server. I object to using the query segment as *the* way of
specifying server-side sub-document addressing because:

  a) You can use the "opaque" part of the URL to do that.
  b) I think that there is a useful distinction to be made between
     addresses (deterministic queries) and queries.
  c) The query segment of URL's is already far too overloaded.
  d) The query segment has many problems regarding I18N etc.
  e) The server has no control over the query segment, and cannot inform
     the client of it's support, or lack thereof, for it.
  f) Makes it harder to support the combination of keyword searches and
     sub-document addressing.
  g) You don't need it.

>If we specify a way of translating TEI extended pointer notation
>into a URL, either into the query segment, or into the URL proper,
>in what way are we saying this is something to be supported by all
>servers?
> 
>Why aren't we saying "here is a language which, if the server
>supports it, you can use, and which, if your users want it, your
>server can be made to support"?

A server has no control at all over what can be sent via a
query, but it does control it's own address space (push vs pull).
Content negotiation cannot (currently) be used to determine if a
server supports such queries, so unless we *standardise* the query
segment syntax, and require all servers to support it, a client cannot
send such queries and expect a meaningful result. In addition, if we
are going to do anything at all to standardise the syntax, I would
recommend *strongly* against using the query segment, and instead use
a mime body. This does impose a cost in complexity, but is far more robust. 
 
>  a.  in the query section:
>      http://www.uic.edu/x/y/z.xml?/tei/id(p23)child(1,emph)
>  b.  in the fragment identifier the same way
>      http://www.uic.edu/x/y/z.xml#/tei/id(p23)child(1,emph)
>  c.  in the 'indeterminate form' this way
>      http://www.uic.edu/x/y/z.xml\265/tei/id(p23)child(1,emph)
>  d.  in the URL-proper form this way
>      http://www.uic.edu/x/y/z.xml/teiq/id(p23)/child(1,emph)
... 
>  * the client sends the query form (a) to the server in
>    its entirety and gets back exactly what was pointed at(1);

Has all of the problems I outlined above.

>  * for locators of form b, the client strips off the fragment
>    identifier, sends the part before the '#' to the server, and uses
>    the rest to navigate in the document sent back

Fine.

>  * when the indeterminate form c is used, the client and the server
>    negotiate using some method outside the scope of this standard
>    to decide exactly what the server returns and what the client must
>    do to it by way of navigation afterwards

Content negotiation *could* be used for this, though this is currently
not widely supported in clients or servers (the reason why I said it
currently cannot be used).

>  * when the URL-proper form d is used, something else happens ...

Under the server's control (server's address space).
 
>If we said something like that, in what way would we be saying that
>*all* servers *have* to support TEI queries?  A server that doesn't
>support them would not respond usefully to queries other than
>the fragment-identifier form.  Nu?  If I have documents there, I
>won't use locators of forms a, c, or d -- any more than I can use
>CGI-based URLs on a server where I don't have write permission in a
>directory the server will execute CGI scripts from.

Right. The point is that a client can never know when it can, and
cannot send such queries, but the server controlls the *addresses*. 
 
>I'm also puzzled because I thought, some time ago, that Gavin was
>arguing vociferously for a locator format that could, in principle,
>be used to trigger server-side tree-traversal (there!  I managed to
>avoid saying whether it is a query or an address!).  But you now
>seem to be arguing against an ERB decision the main point of which
>seems to me to be to support such a locator format.  What is wrong
>with formats a, c, or d in this regard?

I am very much in favor of a standard locator format for addressing
components of a heirarchy. I am *not* in favor of the ERB's proposed
method (the query segment). Of all the above, I prefer (d) as the
standard way, though I would prefer a different syntax. 

>In the short run, I'd like to be able to exploit existing software as
>much as possible; that means, I think, that I'd like to be able to
>other locators using '?', for use when I know the server in question
>is XML-savvy.

The assumption here is that the *client* is smart enough to know how
to generate the queries, and that some way of communicating
capabilities is available.

I think we have different combinations of capabilities:

   1) Dumb client, dumb server.
        - Just send http://foo.com/foo.xml
   2) Dumb client, smart server
        - Server controls the address space, and generates URL's in
          the form it likes. 
   3) Smart client, dumb server
        - Use fragment specifiers.
   4) Smart client, smart server
        - Currently an open question.

Note that 1, 2, and 3 require nothing more than *opaque* addresses
because what is being sent from the server is always a single object
(though it *may* contain pointers/entity references). Note that they
also do not require any communication of capabilities. Realistically,
cases 1, 2 and 3 are by far the most likely in the immediate future.

Case 4 is the most interesting. It requires some capability detection,
which by itself indicates client and server-side smarts. For this, we
*may* need to (eventually) standardise some syntax (see below for
arguments against this), though I think TEI Xptrs are probably far too
limiting. In case 4, it seems perfectly reasonable for a client to
send a transformation specification to the server (effectively what a
query that returns a node list is), and for the server to send back
the results of the transformation. In most cases, the client would be
driving the entire process. DynaWeb can support something like this
today, though currently we have no clients smart enough to do anything
meaningful. Such a scenario has many interesting problems, like how
does one control resource usage etc.

I think that in the general case, it will be very hard to make
clients smart enough anyway, as things like chunking and addressing
require intimate knowledge of the data. Even if there were clients that
*were* clever enough, I do not see the value of them driving the
process, as the intelligence will be stored on the server somewhere
anyway (in a DSSSL specification, in a script, or stylesheet). The
server will eventually have to interpret the information, so I cannot
see the purpose of not having it do it directly and then simply using
pointers to objects in it's address space. 

Most cases where it is desireable for a client to be smart do not
involve a server at all (or just treat the server as a file server). 
This is because, in actual fact, a client and server are *a single
application*. At some point, some separation of workload is important,
and for distributed cases, it is conventional wisdom that heavy data
manipulation take place in the server for performance reasons.

>I think Gavin has argued in the past for incorporating the whole
>thing into the URL pathspec, using something not unlike the fourth
>form, if I understood him correctly.  Two questions:  (1) is form d
>something along the right lines?  and (2) what are the advantages and
>disadvantages of a form like d (or of a form such as you propose, if
>not d-like) vis-a-vis forms a, b, and c?

The main reasons, I outline above. One further reason is that form (d)
will work well with *all* the scenarios I outlined above
(1,2,3,4), and still leaves the query segment for things like keyword
searches.

Received on Sunday, 30 March 1997 23:33:43 UTC