[ticker-dev] new revision of ticker v3 spec

[Blaize Rhodes]

I know this has been said before, but...

I think that the whole idea of a tickertape message format is contra
the elvin philosophy (which I see as allowing increased scalability by
decreasing coupling between applications).  Message formats are like
channels in the effect that they have on msg distribution (though
perhaps at the higher level of granularity  of tuple collections and
not at the individual tuple level (where coupling occurs in channel
based services)).  I reckon a better approach would be i) to ascribe
semantics to certain attributes (ontology-style) and then, ii) if you
like, apply your MUST and MAY conditions to the ontology to define
what's allowed in a standard "tickertape" msg.

The difference is that by defining attribute semantics separately you
allow reuse of those attributes in other msg formats and decrease
coupling between applications based on the msg format adopted.  The
advantage this *may* bring is that at some stage previously unforseen
applications can access the information in the attributes without
having to know about the msg format(s) in which that attribute
appears, i.e it decreases coupling between applications.

Like I said, it has been said before, but I can't help feeling it's
anti-elvin doing it this way .

cheers
   blaize


----- Original Message -----
From: "David Arnold" <arnold at dstc.monash.edu.au>
To: <ticker-dev at dstc.edu.au>
Sent: Thursday, October 10, 2002 5:11 PM
Subject: [ticker-dev] new revision of ticker v3 spec


> i've put a revised specification of the Tickertape v3 protocol on
> DSTC's FTP site for your comments
>
>
ftp://ftp.dstc.edu.au/DSTC/elvin/draft-arnold-ticker-chat-v3-01.txt
>
> for reference, the previous draft remains at
>
>
ftp://ftp.dstc.edu.au/DSTC/elvin/draft-arnold-ticker-chat-v3-00.txt
>
> changes in this revision:
>
> 1. "Replaces" is now a renamed "REPLACEMENT" with identical
semantics.
>
> 2. attachments now use the "MIME-Attachment" attribute, rather than
>    "Attachment", and are a string, not an opaque.
>
>    this has been quite controversial, and i'm not sure that this is
>    the best compromise.  i'd encourage people to speak up if their
>    needs are not met ...
>
> three outstanding issues remain from the first draft (replaces has
> been resolved).  these are: security, the semantics of the
> Distribution attribute, and the lack of explanatory and motivational
> text.  comments and contributions to any of those would be great :-)
>
> see
>
>
http://elvin.dstc.edu.au/ListArchive/ticker-dev/archive/2002/04/msg000
02.html
>
>
> thanks ...
>
>
>
>
> d