On Thu, 16 Dec 2004 16:07:11 +0000, Graham <[EMAIL PROTECTED]> wrote: > On 16 Dec 2004, at 1:53 pm, Danny Ayers wrote: > > > What if they receive multiple, non-identical versions of the same > > entry from different sources? > > Admittedly there isn't a conflict resolution defined for core RSS 1.0 > > components, e.g. where only a single value is mandated, but for > > extensions (which we are talking about here) the RDF model is clear > > (there is no conflict). > > Well you have 2 (or 3) choices: > 1. Use the newer entry > 2. a) Mix all the elements in one <entry> container > or b) as a), but remove duplicately named elements. > > Option 1 requires app-specific knowledge, which RDF can't help you > with. Neither 2a or 2b will necessarily produce valid results, but > again, I'm not aware of a feature in RDF that will help.
What helps in RDF is that according to the model, there is no such ambiguity at the common language level - there are no choices. This provides independence, orthogonality between the message-passing and the application-level interpretation. For example, say the following came from sourceA: <item> <xx:season>Spring</xx:season> </item> the following from sourceB: <item> <xx:season>Summer</xx:season> </item> assuming both items have the same id (however expressed), everything else removed for clarity The RDF interpretation would be two statements, which could be wrapped back up into pseudo-RSS as: <item> <xx:season>Spring</xx:season> <xx:season>Summer</xx:season> </item> The RDF/XML interpretation mechanism provides clear communication of data within a known data model. It's an unambiguous message in this model. What the application does with it is another matter - it's a different layer. But without such a mechanism, the choices are back down at the level of XML syntax, there isn't even a domain-specific grammar to draw on. > (also please don't use the word "receive", we request things around > here) I'd suggest this all occurs above the wire protocol, but ok, I'll try not to ;-) Cheers, Danny. -- http://dannyayers.com
