Robert Sayre wrote:
Ben Lund wrote:
That depends entirely on the application you have in mind. For end- aggregators, it's mostly fine that they can ignore things they don't understand. But what about aggregating intermediaries? Unless there's a defined extensibility model, there's a large chance that the extra data in the exensions that the aggregator doesn't understand will be lost. RDF in RSS 1.0 make this a very simple problem to solve, whereas arbitrary XML namespaces makes it fiendishly difficult.
Could you show us an example? I'm having a hard time understanding why the intermediary could pass on blobs of (X)HTML but not blobs of XML.
Sure (but bear in mind that I said it would be fiendishly difficult, not impossible):
I'm thinking of two use cases here:
1) Aggregating information where two different trusted sources both publish data about the same item. For example, a feed from a science publisher that gave the bibliographic metadata, and a feed from a citation indexer gave 'cited by' information. How does the intermediary concatenate the two blobs of XML? Remember, I'm talking about situations where the intermediary doesn't understand the namespace being used, so from the point of view of the aggregator, the two blobs look like this:
<entry> <id>http://www.example.com/item1</id> <title>Blah blah</title> ... <xyz:tag1>gfdgfdgfd</xyz:tag1> <abc:tag2> <xyz:tag3>gfdgfd</xyz:tag3> <xyz:tag3>65454343</xyz:tag3> </abc:tag2> </entry>
and
<entry> <id>http://www.example.com/item1</id> <title>Blah blah</title> ... <xyz:tag4>gfdgfd</xyz:tag4> <xyz:tag4>bvcbvvcbvc</xyz:tag4> <xyz:tag4>ytytryrt</xyz:tag4> <xyz:tag4>6768875</xyz:tag4> </entry>
There's no easy way of working out how to combine this information. However, with RDF, you can just concatenate the triples.
2) Aggregating feeds from different sources, and then allowing new feeds to be generated based on queries to arbitrary fields.
This means that the aggregator has to capture any incoming data in some sort of schema. In my experience its easier to do that if that incoming data already has a data model more contrained than the XML hierarchical model.
I also don't understand why including rdf:RDF in atom:entry is insufficient. You'd have to consume it with an RDF parser and it would come in a container that isn't RDF itself, but I don't see a problem.
My view is that the RDF model buys you everything you need at the moment for an extensibility model -- that's why we use RSS 1.0 currently. So, I don't particularly have a problem with the approach of putting rdf:RDF in an atom:entry. But that does beg the question of why Atom needs two separate data models.
Ta, Ben
******************************************************************************** DISCLAIMER: This e-mail is confidential and should not be used by anyone who is not the original intended recipient. If you have received this e-mail in error please inform the sender and delete it from your mailbox or any other storage mechanism. Neither Macmillan Publishers Limited nor any of its agents accept liability for any statements made which are clearly the sender's own and not expressly made on behalf of Macmillan Publishers Limited or one of its agents. Please note that neither Macmillan Publishers Limited nor any of its agents accept any responsibility for viruses that may be contained in this e-mail or its attachments and it is your responsibility to scan the e-mail and attachments (if any). No contracts may be concluded on behalf of Macmillan Publishers Limited or its agents by means of e-mail communication. Macmillan Publishers Limited Registered in England and Wales with registered number 785998 Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS ********************************************************************************
