On Saturday, January 8, 2005, at 02:59 AM, Danny Ayers wrote:
Say your system is aggregating material from two sensors, and you get the following, one from each:
<entry> <id>http://123</id> <date>2005-02-02</date> <geo:x>10.1</geo:x> <geo:y>57.3</geo:y> </entry>
<entry> <id>http://123</id> <date>2005-02-03</date> <seismo:magnitude>7</seismo:magnitude> </entry>
It isn't clear how these should be merged - does the entry with the later date replace the earlier one? The (presumably) desired behaviour is for the geo+seismo properties all to appear as elements under (properties of) the entry. Mapping syntax to a model can help decide what to do *in the general case* rather than per-extension. As it happens, RSS/RDF would only go part of the way with something like this - you'd get the desired merged entry, but with two dates.
Unless we have a way to track which parts of an entry came from which source (which it sounds like we don't yet), I'd have to say that merging entries seems like a bad idea. Perhaps a future version of Atom developed after methods of doing that have been refined can be made to take advantage of them. Your example does clearly show the value of being able to merge entries, but as far as we are from being able to do it properly (in the general case, that is--one could certainly write application specific code to merge the entries in the example), I think we should drop it as a goal for now. I could see sense in wanting to put both of these entries into a single feed as a means of collecting their data (in which case, the question arises, would that violate the "unique ID' restriction? are they both the same entry, and thus able to have the same ID?), but that's probably as far as we can go.
geox = GetElementContent("/geo:x"); geoy = GetElementContent("/geo:y"); magnitude = GetElementContent("/seismo:magnitude");
geox = GetAttribute("/geo:coords/@x"); geox = GetAttribute("/geo:coords/@y"); magnitude = GetElementContent("/seismo:magnitude");
Yes, trivially different, two extra lines of code. Potentially for every developer, for every extension.
I think we're looking at this differently--I see two DIFFERENT lines of code, not two EXTRA lines of code. Either the geo extension puts x and y into attributes, or it puts them into child elements--the way that particular extension works isn't going to vary from feed to feed, and thus will require the same amount of code whichever way it works. Am I missing something?
Antone
