RE: Syntax and semantics.

I do believe that that most (probably all) things that call themselves
protocols are locked into a single syntax and transport mechanism.  My point
is that it is still z39.50, even if it is encoded in a new syntax and sent
over a new transport mechanism.  So, z39.50 is NOT a protocol.  (That's too
strong.  Z39.50 IS a protocol today.  I want to separate the z39.50
semantics from the syntax and transport layer.  Then the protocol is Z39.50
encoded in BER and sent over raw TCP/IP.  And, in fact, there is an RFP that
describes just that.  I'm going to come out with an RFP that says how to do
z39.50 in XML embedded in HTTP and another RFP that says how to do z39.50 in
URLs.)

I think we've let the interoperability concern paralyze us and has caused us
to miss some opportunities.  We sit around tables telling each other that
community X is doing searching stuff and they're going to have to relearn
all the things that we've already learned and wouldn't it be so much better
if they just used z39.50.  But, community X doesn't want to do BER and they
don't want to do raw TCP/IP and we just let them drift off on their own.

But, if we stop insisting that they have to use our protocol to use our
semantics, then they get to take advantage of all the work we've done.  What
they lose is access to all our databases.  But, if they use our semantics
and there is a business reason for community X to access our databases, or
vice versa, then gateways are nearly trivial.

Ralph

> -----Original Message-----
> From: Sebastian Hammer [mailto:quinn@indexdata.dk]
> Sent: Monday, January 15, 2001 4:05 PM
> To: LeVan,Ralph; 'ZIG'
> Subject: Syntax and semantics. WAS: RE: Init is dead?
> 
> 
> At 14:38 15-01-01 -0500, LeVan,Ralph wrote:
> 
> [Ralph moves the discussion to include the encoding issue so 
> I will follow 
> suit]
> 
> >All implemented standards have three component: A semantic, 
> a syntax and a
> >content rule.  The combination of the first two is usually called a
> >protocol.  (Actually, I guess there is a fourth component, 
> the transfer
> >mechanism, which is raw TCP/IP for us.)  In the case of 
> z39.50, we've been
> >locked into a single syntax (BER) and have gotten away with 
> calling z39.50 a
> >protocol.
> 
> Is that paragraph meant to suggest that you feel most 
> protocols are NOT 
> locked into a single syntax? I think that would actually be 
> pretty unusual. 
> Running an OSI stack would, in principle at least, allow you 
> to negotiate 
> other encodings than BER (including, presumably, XER). TCP/IP doesn't 
> directly support that kind of negotiation, and as a result, I 
> believe that 
> the vast majority of Internet protocols are pretty rigid in 
> terms of their 
> syntax.
> 
> I agree completely that by dropping the init or changing the 
> syntax, we are 
> in fact creating a new protocol - the first and most 
> noticeable effect of 
> which will be that interoperability with old implementations 
> becomes more 
> complex.
> 
> We will need to think carefully about how we talk about these 
> things. At 
> present, the Z39.50 protocol gives you relatively straightforward 
> interoperability with anything deployed since 1992 (thanks 
> partly to the 
> Init service I might add). A new "Z39.50 protocol" throws 
> that to the wind, 
> gateways or no gateways. Three new "Z39.50 protocols" do it 
> thrice over. 
> How do we avoid chaos when Z39.50 ceases to imply syntactic 
> interoperability.
> 
> I think at the meeting, Ralph, you hinted that perhaps new syntaxes 
> (protocols) should be seen as parallels to new APIs - just 
> other ways of 
> representing the same thing for different purposes. Perhaps 
> it should be 
> seen as a parallel to CORBA, which, I believe, allows 
> different language 
> mappings and even different protocols - but it suggests only 
> one protocol 
> for cross-broker interoperability - the IIOP.
> 
> Maybe (just maybe) it makes sense to keep crusty old Z39.50 
> over BER as our 
> internet interoperability protocol. After all, it works, and 
> we're not 
> alone - LDAP, SNMP and SSL use it to good effect.
> 
> Dropping the Init I see as a less challenging issue. It's not 
> hard to make 
> optional for most client OR server developers, and it would 
> be a pretty 
> simple switch to set in your client setup. Most old-style 
> servers would 
> probably also fail fairly gracefully (by dumping the 
> connection) if they 
> were confronted with an un-initialising client.
> 
> --Sebastian
> --
> Sebastian Hammer        <quinn@indexdata.dk>            Index Data ApS
> Ph.: +45 3341 0100    <http://www.indexdata.dk>    Fax: +45 3341 0101
>

Received on Monday, 15 January 2001 16:18:58 UTC