Re: A Note on URC Querying

Mark Madsen (msm@ansa.co.uk)
Mon, 26 Jun 95 16:16:21 BST


From: Mark Madsen <msm@ansa.co.uk>
Message-Id: <9506261516.AA07709@euclid.ansa.co.uk>
Subject: Re: A Note on URC Querying
To: terry@ora.com
Date: Mon, 26 Jun 95 16:16:21 BST
Cc: uri@bunyip.com, msm@ansa.co.uk
In-Reply-To: <9506251322.ZM26248@dmg.west.ora.com>; from "Terry Allen" at Jun 25, 95 1:22 pm

Terry Allen writes:

> Ron asks whether his own example, cited by Mark, is a good way
> to go; it included METHODS and INTERFACE elements.  And he

Perhaps I should explain that the example I cited was my construction,
built on the basis of an example constructed by Ron, who shouldn't
have to take the blame for any hare-brained ideas I come up with.

I'm carrying the quoted example below to maintain the context for the
discussion.

> asks whether we could use processing instructions to convey
> that info instead.  Here's the example:
> 
> > <!doctype urc SYSTEM "urn:x-dns:uri.ansa.co.uk:method-dtd-7">
> > <urc>
> > <author method="m1">Smith, F.</author>
> > <subject method="m2">Cats</subject>
> > <URL></URL>
> > <results>
> > (Initially empty, this container holds the results of the
> > searches.)
> > </results>
> > <methods>
> > <m1 lang="niceScript">
> > (A script written in the niceScript(TM) language that
> > takes an argument which is the contents of the author
> > field, splits on the comma, looks for an exact match
> > of the last name and a first name beginning with what
> > is left after the split. Returns NULL if there is no
> > match, and a list of attribute:value pairs if there is.
> > The attributes in this list lie in the intersection of
> > those listed in the template and the Attribute-set of
> > the candidate URC and the values are taken from the
> > candidate URC.)
> > </m1>
> > <m2 lang="nastyScript">
> > (A script that takes its argument from this template URC,
> > compares it with the subject fields in the candidate URC,
> > and returns TRUE if any of the subject lines contain the
> > string "Cats", FALSE otherwise.)
> > </m2>
> > </methods>
> > <interface>
> > <main lang="pseudocode">
> > bind input to name GLOB
> > if (invoke(SELF.m2(GLOB))
> > insert(SELF.results, SELF.m1(GLOB))
> > </main>
> > </interface>
> > </urc>
> 
> This URC describes "all the works of {author} on cats currently
> returned by the search procedure described."  At least when you
> run it the first time (what happens when you run it again and
> the result differ?  never mind, it's just an example).  And
> it supplies the value for {author}.  The script itself could
> be used for any author (the way the example is written; you
> could generalize it for subject too), so really ought to be
> an object in its own right, with its own URC, which you
> can point to from this URC.  

Yes, the script itself could legitimately be wrapped as a URC, as was
made explicit in Ron's subsequent example.  This is exactly what I was
getting at in presenting this way of looking at URCs.  A URC really
can be treated as an object.  And if it can, then it should, because
of the obvious benefits that come from dealing with objects.

[An aside in response to Terry's aside: if you invoke the search
method a second time and the results differ you have to conclude that
something changed in the meantime (is humour allowed on this list? :-)
It's not necessarily a flippant answer, because then you may want to
invoke other methods that determine what it was that changed: the
resource itself, the location of the URC object within which the
method was invoked, etc.]

> You could use SGML processing instructions here, but when you
> parse the URC with SGML you're probably just going to be setting
> up a table of values that match known semantics; then the script
> going to be called by some other, resolving application.  That

I would prefer to see all this defined in a way that didn't depend on
a particular language.  (I am perfectly happy to see SGML used as the
specification language for URC syntax.)

There are a lot of languages out there now, and there will be many
more in future.  We should make sure that we can take advantage of
their new features when they arrive.

Two points about my example that I would like to re-emphasise:

(1) The computational model implicit in my construction makes very few
assumptions about the object environment in which processing is
performed.  Mainly it assumes the possibility of mutual cooperation
between certain objects.

(2) It emphasises that not only may the URC objects have different
methods and interfaces, but these methods and interfaces may be
written in different languages appropriate to different environments.
This means that if I only want to take advantage of the most popular
environment, I may be able to use simple URC agents that only employ a
single language interface, whereas if I want the URC agent to be able
to travel across boundaries or through gateways, then I will need to
use a more sophisticated URC that has a variety of interfaces, each
containing appropriate methods in appropriate languages.

> application needs to know what to do with 
> 
> <methods scheme="urn:foo"> 
> 
> where "urn:foo" points to the script, but that info can be 
> contained in the definition of <methods>.

Exactly.  Objects should be as autodescriptive as possible.  One issue
that I think has not been solved yet is whether the invocation entry
point should be built into the URC specification or whether it should
be defined as a result of the binding between server and URC
object/agent.

Question for Peter Deutsch: Peter, could your URN resolution scenario
(a la Silk) share the kind of framework that Ron, Terry and I have been
discussing for URCs?  It seems to me that there is no particular cause
for conflict.  Can you see any problems in amalgamating them?

> Terry Allen  (terry@ora.com)   O'Reilly & Associates, Inc.
> Editor, Digital Media Group    101 Morris St.

Regards,
         Mark.
--
________________________________________________________________________
Mark Madsen: <msm@ansa.co.uk> <URL:http://www.ansa.co.uk/Staff/msm.html>
Information Services Framework, The ANSA Project, APM Ltd., Castle Park,
Cambridge CB3 0RD, U.K.  <URL:http://www.ansa.co.uk/>;  <apm@ansa.co.uk>
Voice: +44-1223-568934; Reception: +44-1223-515010; Fax: +44-1223-359779