Re: Personalization?

[Robert Sayre <mint@xxxxxxxxxxxxxxx>]

On 5/18/04 5:03 PM, "Danny Ayers" <danny666@xxxxxxxxxxx> wrote:

> 
>> / Tim Bray <Tim.Bray@xxxxxxx> was heard to say:
>> | In the last paragraph of his piece this morning
>> | <http://weblog.infoworld.com/udell/2004/05/18.html#a1002>, Jon Udell
>> | talks about personalized RSS feeds.  I think he's right, and in fact
>> | I've subscribed-to/built a few for myself.  This note is to wonder out
>> | loud if there's anything that we need to worry about in the Atom
>> | design to help make sure that this kind of thing is well-supported
>>  
>> 

> 
> There is a choice, either keep the spec as-is, leaving it up to
> developers of individual applications (both producer and consumer) to
> agree on their own privileged languages for extension, or specifying how
> extensions can be interpreted in a consistent fashion.
> 

Maybe we should look at this on an individual element basis, rather than
trying to figure out a general approach to extensibility.

I suspect that dc:subject will become about as useful as

<META NAME="KEYWORDS" content="..." >

is in HTML. Viagra spammers will probably be early Atom adopters. This
suspicion leads me to examine our Link Construct. I'll summarize the
approaches that have been discussed lately:


Atom 0.3
---------------------
<link rel="alternative"  href="..." type="text/html" />

This approach borrows from the HTML link element, and so inherits the
less-than extensible @rel. It has namespace issues.


Enter PaceLinkRelMechanism
---------------------
<link rel="mynamespace:alternative" href="..." type="text/html" />

Now @rel is extensible via namespaced attribute values, but no existing XML
tools support it (I think). That's a huge downside.


A third approach, discussed on atom-syntax (Graham?)
---------------------
<foo:bar atom:href="..." atom:type="text/html" />

Global link attribs allow arbitrary elements to be identified as Link
Constructs, at the cost of ditching the accessible <link> syntax.


I think we're well into SemWeb/RDF territory by the third suggestion, so
perhaps there are more options on the way from the RDF folks. RDF can handle
this problem, but can it handle this problem while keeping the easy things
easy? My personal definition of "easy": an RDF-naïve person would be able to
use the construct without their mind having to wander from the narrative
that their feed is creating. The thought-process should be similar to the
one for generating an html <table>.

To me, a uniform method for extensible <link>s seem pretty critical to
content-based pubsub for source credibility reasons, but I'd love to hear
Bill's opinion.


Robert Sayre



>> <feed xmlns="http://purl.org/atom/ns#"; version="0.3" xml:lang="EN-us">
>>  ...
>>   <entry>
>>      <title>CSS or Tables?</title>
>>      <link rel="alternate" type="text/html"
>> href="http://norman.walsh.name/2004/05/18/css"/>
>>      <id>http://norman.walsh.name/2004/05/18/css</id>
>>      <issued>2004-05-18T12:28:00Z</issued>
>>      <modified>2004-05-18T16:33:43Z</modified>
>>      <dc:subject
>> xmlns:dc="http://purl.org/dc/elements/1.1/";>SelfReference</dc:subject>
>>      <dc:subject xmlns:dc="http://purl.org/dc/elements/1.1/";>CSS</dc:subject>
>>      <summary>A few thoughts about CSS, tables, and the mechanics of page
>> layout.</summary>
>>   </entry>
>>