Re: [syndication] envelopes vs. payloads, calsch,

[Ian Graham <ian.graham@utoronto.ca>]

On Sun, 9 Jul 2000, Phil Wolff wrote:

> Standards groups (like this one has become) often need to draw a line 
> declaring what is in and out of the next major spec release. Do you 
... 
> (a) further separate the envelope from the payload? 
> 
> Can the spec allow just about anything to be syndicated, beyond news 
> items? 

I would expect, in the long run, syndication of all sorts of data
(including some we haven't invented yet) 

> I agree about syndicating events; they are a natural. About the 
> Calendaring and Scheduling standard, (1), I'm not sure if the ietf 
> calsch working group ever finished, but it appears so. I'd really 
> like to be able to include in my web pages things like Craig's List 
> events, ZDnet conference listings, my brother's band's gigs, 
> reminders for when my bills are due. I'd also like to syndicate 
> project to-do lists, bookmark collections, and even my resumé (2). 
> 
>  (1) http://www.ietf.org/html.charters/calsch-charter.html
>  (2) http://www.hr-xml.org/schemas.html

The Calsch group is still quite active (lates WD is March 10th), and I
believe there are bunch of product that support the current iCalendar
format. 

One of the issues I see is that, when I am distributing things
like conference schedules or university seminar listings, I want
to include details about the event (abstract, room numbers, 
graphics, etc.) that are not supported by the iCal stuff, which
is targeted at a different purpose. It's also not XML (yet),
so there is no way to escape to a different namespace to include
such information. 

> (b) include payload DTD's by reference? 
> 
> A great deal of the value this group brings is in the envelope. Why 
> not permit inclusion by reference of payload structure? Assures 
> notice of payload structure changes. Let's you choose to support this 
> particular channel, or not. And support the myriad of content types. 

Well, I don't like the idea of binding to a DTD -- SOAP (I believe)
lets you use namespaces to define what the 'payload' is (please no
more on what a namespace is or isn't ;-) ). But the idea of multiple
'payloads' (or whatever it is called) seems a good one. The question
I think Dave is posing (in a later letter than the one I'm 
responding to) is: should payload construction and delivery be
done using SOAP, in which case you could simply plop an RSS payload
inside it, and be done. The argument I think others ar making is
that there is probably a set of 'generic' syndication properties
that will be true for all syndicated content, which may or may not
warrant a 'second' wrapper layer around the syndicated 'payload'.
Or - should it be merged into a separate payload format parallel
to  but differently optimized than SOAP. 

I'm going to read the SOAP stuff tonight (I know very little about it).
My tendency, however, is to reuse what exists, and not spend time 
recreateing what smarter people have already thought through.

As for a 'second' wrapper layer, I don't think we can say if it's useful
or not until we've worked through some examples of syndicated job
postings/event listings/news articles/whatever/, and see what
commonalities exist.

Ian
--
Ian Graham ..........................  http://www.utoronto.ca/ian/
i a n   d o t   g r a h a m    a t    u t o r o n t o   d o t  c a 
Tel: (416) 978-4548 .......................... Fax: (416) 978-7705