> I think this is a good idea, as long as the "more complete" XML is
> still of the RSS/RDF variety. That is, the compact version would be
> of the .9x variety, and the complete version would be of the 1.0
> variety (with modules etc). This could apply to individual items of
> a feed, or the entire feed itself.

I don't know about this suggestion in that you're proposing the mix
of 0.9x and 1.0 formats. While an environment may understand both is
it reasonable to expect them to switch on the fly?

I'd be more inclined to suggest the "more complete" document use ONLY
RSS-1.0 style format. Or better yet, RSS-2.0 (being 0.9x with
namespaces and RDF as optional)

> This should be cause for a new GUID. You mentioned in another place
> (forget where exactly) the idea of a "path." I looked into the
> pointers you provided and agree that it's a good idea. If I modify
> an item I have consumed and then redistribute it (with
> modification) it should be given a new GUID, and have another
> element added to the path. (perhaps the path ought be the string of
> GUIDs, new to old)

I'm ok with the idea of attaching a new GUID when an environment re-
routes the item; even without additional modification. The re-
routing of an item into a fresh space is itself often a significant
bit of metadata. I'd suggest, however, the Path of previous
identifiers not be concatenated into a string. I'd prefer an list of
some sort. Do existing XML environments support ordered arrays? Or
would we be better served attaching an array of structs to allow for
attaching the server URL, item URL, etc... ?

-Bill Kearney