Hey Folks,
With yesterdays build release of IE7, it seemed appropriate to run a quick inventory check to see where things stand in regards to the derived MS/RSS conversion of a fairly element/attribute usage heavy Atom feed. Here's the overall breakdown.
Process:
I took a quick snapshot of the atom feed from my personal blog -- put it on a medium dosage of Atom-RNC approved steroids (using Uche's latest RNC update >
http://copia.ogbuji.net/blog/2006-02-06/Small_fix_ <), and ran the result through the official live instance of the feedvalidator -- minus the incorrect encoding being reported (obviously a simple fix -- will do that after
I finish to the current mapping and related transformation file) it validated.
I then subscribed to this feed in the latest (March 20th) build of IE7, extracting the transformed result to compare against the original looking for areas of potential data loss.
The two docs:
Original:
Derived:
Initial analysis: From what I can tell, it seems that theres is only one significant loss that can not be extracted, interpolated, or otherwise derived from somewhere within the transformed result doc:
Original:
<category label="foobar" scheme="http://www.xsltblog.com/tags" term="Internet Explorer 7.0"/>
Derived:
<category domain="http://www.xsltblog.com/tags">Internet Explorer 7.0</category>
Obviously the derived category element is missing: label="foobar"
I should note that its only the first entry that I added @label and @scheme to the category element. The rest contain only the required @term.
I'm not sure if this, in and of itself, caused the loss. I guess it would depend on how they go about the conversion, (e.g. placing weight on the number of occurrences of an attribute, disregarding that which falls below a certain determined criteria? I don't know... just throwing something out there for the sake of throwing something out there :)
Sean, can you verify this and determine if its something on your side of the lake, or on mine?
Beyond this, it seems that everything else *SHOULD* be able to map back fairly well.
The areas that are currently untested, and potentially a point of concern (that I can think of off the top of my head, anyway)
* undefinedContent of element atom:category
* any extended usage of xml:base and xml:lang
Some areas worth noting:
The following elements seems to be exact copies (including attributes) of the originals:
atom:link
atom:author
atom:name
atom:name
atom:email
atom:uri
atom:contributor
atom:name
atom:email
atom:uri
atom:published
atom:summary
Overall it seems to me the MS/RSS team has done a pretty fantastic job of ensuring a fairly high quality conversion, making exact copies of those elements and their associated attributes that did not allow for a clean conversion to the MS/RSS format and still maintain any hope whatsoever of making the round trip back to its original Atom format.
A BIG PHAT thanks to the MS/RSS team for this! There's a significant amount of conversion work to get back to the original Atom format that is no longer required because of their efforts. So again, thanks to Sean and the rest of the MS/RSS folks for their extended efforts on this.
I will be posting this report to the http://trac.understandingatom.com/wiki/AtomicRSS.NET site, as well as adding the transformation files to the repository (available from this same interface) as soon as I can finish it up and verify to some level of certainty that the original file and the conversion back appear to be the same file. Of course, if this is simply not possible I will post what I have, and report the problems areas back to this thread.
Enjoy your dev-day! :)
