[ticker-dev] new revision of ticker v3 spec

[Ian Lister]

On Thu, 10 Oct 2002, David Arnold wrote:
>ok, so let's find a better way.

That would be good, but I am also OK to let Tickertape continue in the
direction it is currently going, if that is what others want.

>  Ian> Unfortunately the view is that `Tickertape is not Elvin'.
>
>i don't see how that is either unfortunate or relevant.  but perhaps
>that's because i hold that view?  please feel free to enlighten me.

If the feeling is that the Tickertape way is divergent from the Elvin way
rather than aligned with and the best example it can be of the Elvin way
then Blaize's observation that giving standard meanings to attributes
rather than whole notifications is more in the Elvin way is not relevant.
So my point is relevant because it is tied to whether Blaize's point is
relevant to Tickertape. I think that this is unfortunate because I think
Tickertape has a lot to give Elvin and other Elvin applications (and that
Tickertape and other Elvin applications can potentially gain by sharing
rather than being independent protocols designed only for their own
purposes and not for future extension or use in ways that are not
currently done).

>  Ian> I have also detected a significant anti-ontology feeling at
>  Ian> various times, particularly when Julian suggested it earlier
>  Ian> this year.
>
>i personally suffer from scepticism, but i wouldn't characterise my
>position as "anti-ontology".

It's not just you I've got the feeling from, but I still think a 95%
effort is still much better than ad-hoc use of attributes.

>i'm willing to work on such a beast, but contributions to the ticker
>spec so far have been conspicuous by their absence, and i'm not going
>to take on responsibility for generating an ontology as well.
>
>i'm happy to collate and publish submissions, if you like.

I am also happy to do it, and I probably should do it given that I'm the
one keen on it and you're the sceptic :-)

FWIW I think one of the main problems with an ontology for Elvin is going
to be the problem of encoding, due in part to the simple data structures
Elvin provides, but mostly because of a number of other reasons. At the
simplest level an example is the problem of units - an attribute `Timeout'
is not useful without knowing whether a numeric value is in seconds,
minutes, or years. Naming attributes `Timeout-Minutes' is not so useful
because it segregates information based on (easily convertible) units
(and/or requires applications to represent the same information in many
different ways). The classic temperature sensor example is another case -
what units is `Temperature' in? Is it reasonable to define that
applications should always use metric units of a particular scale?

The renaming of Attachment to MIME-Attachment is really another example of
the same problem - by specifying the encoding of the attribute's value in
the attribute's name we make it clear what to expect in the attachment,
but if there were other common ways of representing attachments then any
applications that chose those methods would lose any potential for
interoperating with Tickertape's attachments. In this case it seems that
declaring that attachments should be in MIME whenever possible makes
sense, but then perhaps the `Attachment' attribute should be defined to be
MIME and the `MIME-' prefix in the attribute name (which is really only
there to specify encoding) should be dropped.

There are other encoding issues with simpler solutions, such as defining
that lists of values should be `|' separated strings (as the presence
protocol has defined for a few attributes it uses), but richer ability to
represent more structured data in Elvin natively would help. Without it we
rely on ad-hoc methods (such as the `|' list representation) and/or
stuffing external structured formats such as MIME and XML into
notifications, losing ability to (effectively) subscribe to their content.

Any thoughts on any of this? Is this all just evidence that it won't work?

Ian