Re: What I

Michael Mealling (
Wed, 15 Mar 1995 14:51:52 -0500 (EST)

From: (Michael Mealling)
Message-Id: <>
Subject: Re: What I
To: (Jon P. Knight)
Date: Wed, 15 Mar 1995 14:51:52 -0500 (EST)
In-Reply-To: <Pine.3.05.9503151936.E11098-c100000@suna> from "Jon P. Knight" at Mar 15, 95 07:22:38 pm

Jon P. Knight said this:
> On Wed, 15 Mar 1995, Michael Mealling wrote:
> > The problem this causes is that for the user the important information
> > is still stored in the URC and not the resulting template. This means that
> > the final result of the search should be a fully formatted and syntactically
> > rich URC. Therefore there needs to be some method by which the
> > whois++ query can finally resolve into something that isn't a template.
> >  
> > The final solution appears to be the addition of a MODE command to whois++
> > (and possibly SOLO) that allows the client doing the query to request
> > that the server switch protocols (and thus query language and data format)
> > entirely. This allows the same connection to issue the query in whois++,
> > switch MODES to something much more capable, and then reissue a richer
> > query that returns a much richer data element: the final URC.
> I know this is probably heresey and there's some terribly good reason
> why it won't work, but why not have the extracted template have some
> attributes that just say what format the full URC is in and where to get
> it from? You could even make them variants or clusters.  How about
> something like:

> This would let you have multiple full format records with richer data
> representations than the IAFA style whois++ templates, would separate
> URC discovery (using whois++) from retrieval of full URCs (using
> whatever mechanism(s) might be appropriate) and would not require any
> changes to the existing whois++ or SOLO tools.  

The change is rather trivial actually. The way its specified you can just
do a system call and hand the file descriptor to some new server. We
are basically doing what you suggest but for effeciency and implementability
we are making the assumption that the URC will be left in its canonical
format and converted as needed....

> It also allows multiple
> formats of the URC to be held in different locations (coherency is left
> as an exercise for the reader as my old maths textbooks used to say). 
> Of course you'll make more than one connection to get the full URC (one
> for the whois++ URC discovery phase and one for the retrieval of the
> full URC by mechanism XYZ).
> So... what am I missing here? :-)

Your not missing anything. That's one other perfectly valid way of doing
it. We looked at this and decided that since we will probably end up
getting URCs from the authors in one given format (?TEI?) that we could convert
them into whatever format in the server. This makes coherency a none issue
and it also makes it easy to add new functionality for new formats. Its
also easier for sys admins to setup one server suite than two...


<HR><A HREF="">
<ADDRESS>Michael Mealling</ADDRESS>