2Goals and scope of the list
- Jul 2, 1999[ There are now 16 people on this list, with a very good representation of
the people who should be here. I'll put a modified version of this in the
welcome message, so that newcomers are uptospeed-ish. ]
There are a lot of separate efforts to define XML
news/announcement/syndication/resource discovery formats. All of them are
happening behind closed doors, despite people's best intentions. As a
result, we're going to end up with multiple, incompatible overlapping
This list is here to get it out in the open. There are obviously enough
people interested. If we can get everybody to hash out a core, then
individual gathering places (like NetCenter, ScriptingNews and others) can
add featues to a common standard. The trick is to separate the format from
the delivery/presentation mechanism.
I think everybody would agree the first thing we have to figure out is what
the scope of a syndication format is. 'Syndication' may not even be an
There is a lot of work already out there. Other formats that are similar,
and designed/promoted by primarily one entity include:
* RSS (Netscape) - Started it all. Netscape currently working on a new
* ScriptingNews - WebLog. Started with RSS, moved to their own format. Also
working on new version.
* MoreOverNews - proprietary news aggregation site.
and others (list if you know of one)
On the heavier side, there's:
* ICE - true syndication format; request/response format layered over HTTP
POST. Probably too excessive for the uses above.
* RDF - resource description framework. A standard way of describing
metadata. May be good to incorporate this, or it may confuse the issue.
Could someone more familiar summarise?
List Activity and Scope
This is what I had in mind when I suggested the list:
* look into current standards, decide what's usable, where there's overlap
* define the problem - what kinds of things do we want the format to do, and
what is out of scope?
* hammer out a specification. Two major parts are:
- what features a [insert-format here] file must and may have
- which of those features a parser must support
* document it
* produce a reference implementation of the spec, and tools to enable people
to translate to/from other formats, as well as read and write it.
I've already been playing on my own with tools and ideas to get content into
a format, and then drag it back out. Getting everybody to agree on bit in
the middle is what this is all really about for me...
Let's get going!
Mark Nottingham, Melbourne Australia