Re: Atom extensibility

[Robert Sayre <mint@xxxxxxxxxxxxxxx>]

Henry Story wrote:

> The question is exactly how should the interesting discovery that an 
> Atom document is an RDF document [Ø] be used to fulfill the charter 
> requirements on extensibility? 


Have you figured out a way to deal with this:
<link rel="via" href="..." title="..." length="..." />

> So perhaps we can open this thread as a place to post ideas on the topic.


I think the debate is pretty much settled for client GUI software. RDF 
doesn't help a bit. A more interesting situation is a server receiving 
Atom entries to publish. For the purposes of discussion, let's say the 
server trusts the client.

It gets a POST with a fairly average atom entry, but there are 
extensions in funny places. Like most people, the server stores standard 
fields in a relational database, so there are columns for title, 
summary, etc. in a table called something like "journal_entries". It 
would be fairly easy to store immediate children of entry in an 
"unknown_xml" field, and pass them through, but what about the other 
extensions? Using an RDF store might make this problem a lot easier, but 
I don't forsee a mass migration in that direction happening this year or 
next.

POST ...

<entry xmlns="..." xmlns:funky="..." xmlns:rdf="...">
<title>My cat</title>
<author>
<name>me</name>
<funky:thing>adfadf</funky:thing>
</author>
<summary>I took my cat on vacation</summary>
<content ... funky:att="foo">It was really fun</content>
<funky:thing>adfadsfa</funky:thing>
<rdf:RDF>
...
</rdf:RDF>
</entry>

So, what's the algorithm and storage strategy that will allow maximum 
extensibility but not require servers to re-architect?

Robert Sayre