Re: [syndication] Re: eXtensible Content Syndication (the next step for OCS)

[burtonator <burton@relativity.yi.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Morbus Iff <morbus@disobey.com> writes:

> I'm coming in a bit late for this. Sorry.
> 
> First, what are we looking to actually have in the feed list itself? One
> person recently said that the feed list should contain nothing about the
> content of the feed - only about it's location. The reasoning was that the
> content of the feed shouldn't be replicated because the content creator
> could change it at any time.
>
> Personally, I agree with that only a tad bit. I think the reasoning is
> sound - we shouldn't assume too much about the feed (like a never changing
> title or description), but as a client creator, I also think it would be
> stupid.

I mentioned in my initial e-mail that I agreed that this was probably a
technically correct argument, but it has flaws:

What if the content you are syndicating is binary and your syndication engine
doesn't have support for this format yet your client application does.  IE
shockwave, mpg, etc.  There would be NO way for you to index this content.

The point is that we need to keep this open via the use of modules.  If a
developer doesn't want to include metainfo... they don't have to.

> If someone downloads my client, and is provided with a list of 1000 feeds with
> no titles or description, than that basically means I have to waste the user's
> time as I go out and somehow aggregate the title and descriptions into a
> database myself - no user is gonna want to wait 50 minutes while I get all the
> titles and description each time they want to add a new channel (or each week,
> or what have you). They're not going to understand or care, really, that the
> XML format is great and well defined.  They're just gonna care that it's
> taking a hella long time.

agreed.

> So, whether it's a standard or not, any solution I choose is gonna have the
> title and description built into the channel list.

I think it should be modular though...  Probably dublin core.
<snip>

> >- - Doesn't support mime types.  XCS should support both mimeTypes (text/xml,
> 
> Why should we need these again? Just to give more information about the
> feed on the other end and the format in which it's in? If that's the case,
> then it's much like the title and description - something that the user
> controls and can change at will.

True.  Maybe we should move this over into a module.  Good point.

> Burtonator, I don't know how you handle feed updates or "is this feed still
> publishing", but there are a few things that your proposal doesn't address:

ah... yes...  it does :) More on this below.

>  - Aliases. Jeff Barr has a large list of aliases for sites - duplicates
>    of the content, only at different URLs. How would those be handled
>    in the list? I worry that making an entire new <syndication> entry
>    for each will bloat the list. Perhaps we could just add an <alias>?

Most of the work we are doing at OpenPrivacy revolves around Reputation.
Reputation should be used to solve this problem instead of an explicit list.

The Reputation system we are going to be building around sierra
(http://sierra.openprivacy.org) supports arbitrary payloads so a payload could
say:

"url1 is a duplicate of url2"

This would also give you the benefit of our Reputation system including
integrity (everything is signed), distribution, bias (I don't trust this person
but I REALLY trust this on), etc.

>  - Standard junky junk concerning internal usage of the channel in
>    question. Perhaps the following optional module:
> 
>      <internal:added>Jun 12 1999 12:32:45 GMT</internal:added>
>      <internal:filesize>3421</internal:filesize>
>      <internal:error>404 File Not Found</internal:error>
>      <internal:lastchecked>another ISO date</internal:lastchecked>
>      <internal:lastupdated>another ISO date</internal:lastupdated>

Ah... really good point.  I will add this to the spec as a module.  Of course I
will give you attribution...

>    Roughly, "added" would suggest when the channel was first added to the
>    list, allowing queries such as "show me all channels in the past month" or
>    "show me channels within the past two days".

<snip>

> That's it for me this round. Concerning Aaron's followup message, I think
> the dc:language should definitely be as close to required as possible, but
> don't like his attribute loving format. I fear the "use RDF! use RDF!"
> admonishing.

There is certainly nothing wrong with code reuse but it should not be abused.

Kevin

- -- 
Kevin A. Burton ( burton@apache.org, burton@openprivacy.org, burtonator@acm.org )
        Cell: 408-910-6145 URL: http://relativity.yi.org ICQ: 73488596 

Never apply a Star Trek solution to a Babylon 5 problem.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt

iD8DBQE7dvsmAwM6xb2dfE0RAuW1AJ4hAN0KzCt379unPAqeRBLclvxcGwCeKm67
n/uVeqQ+5Yo5abswkNezkww=
=igI4
-----END PGP SIGNATURE-----