[XML-SIG] Content Syndication
Fri, 2 Jul 1999 14:08:35 +1000
> So I'm not understanding something here. Is there supposed to be other
> besides the link? Otherwise, you just end up with a bunch of links and no
> text. Or are you saying that link should be allowed as sub-elements of
> and description? It seems like this may be harder to parse, and it
> makes it less useful as metadata.
#2ish - inline elements. For instance,
<title><link url="http://foo.com/frobnob.html">New widget frobnob
<description>The <link url="http://foo.com/">Foo corporation</link> released
their new Frobnob widget set today at a press conference in Wagga
However, I'm not particularly tied to this. Inline tags seemed natural and
more specific if you want the possibility of multiple and content-sensitive
links in each item. ScriptingNews does the whole
thing, but this seems a horrible hack to me. What if the linetext shows up
more than once in the text? Is it really that hard to parse inline tags?
<description> probably isn't appropriate... perhaps <text>...
One other thing. How do people feel about disallowing embedded HTML in the
> This brings up the issue of what the purpose of the format is. RSS was
> originally intended to be a metadata format. ie: Information about other
> sites. ScriptingNews (and the above description) tend to indicate a
> more of a publishing/syndication approach, where the format *is* the
> not just a description of it. It's a fine line, and I'm not sure what the
> answer is.
This is probably the first (and most important) thing to decide. SN itself
uses the format to publish its entire content, but it's child channels
don't; I think that's the problem.
> > * expiration date - so that content providers can limit how long an item
> > shows for
> per channel, or per item?
I'm thinking both pub and expiration date are per item.
> > I think it would be a good idea to set up a syndication mailing list (on
> > findmail or whatever), so that everyone can meet on neutral ground, and
> > some goals, work out the issues and define deliverables in public.
> > else thing this is a good idea?
> I think it is a fine idea.
Cool. Will announce under separate cover.