Hmm... guess I was a bit off on the links... you need to be logged in as an admin for the links to take you anywhere useful, and even then its not to where I had hoped.
This link, however, will take you to the correct location in which you can select the issue from the drop down. You do not need an account, and can post bugs as anonymous if you would prefer. I am happy to create accounts for those interested, but thats not something that needs to happen first, or ever, to be able to interact with the system.
Thanks again!
On 3/22/06, M. David Peterson <[EMAIL PROTECTED]> wrote:
Hey David,Wow! This is really cool :)Since you have obviously gone to great effort to both test and extract this info, I will take the time to add these as tickets into the Trac database. For now I have added three categories:
On 3/22/06, David Powell < [EMAIL PROTECTED]> wrote:
Wednesday, March 22, 2006, 5:13:05 AM, M. David Peterson wrote:
> Hey Folks,
>
> With yesterdays build release of IE7, it seemed appropriate to run> aquick inventory check to see where things stand in regards to the
> derived MS/RSS conversion of a fairly element/attribute usage
> heavyAtom feed.Here's the overallbreakdown.
> [...]
> Beyond this, it seems that everything else *SHOULD* be able to map
> back fairly well.
There haven't been many changes to the transformation process in this
build, so all of the 15 issues with the Atom transformation in the old
build are still issues with this one.
http://www.imc.org/atom-syntax/mail-archive/msg17898.html
[Quick summary of actual data-loss:
loss of person extensions, loss of timezones/corruption of times, loss
of [EMAIL PROTECTED], titles are flattened to text without preserving
HTML version, loss of category label, xml:base/xml:lang loss,
inheritance of atom:author and atom:rights not handled
]
The last issue perhaps needs some more explanation:
In Atom, the following two entries are equivalent:
a)
<atom:feed>
<atom:author><atom:name>David Powell</atom:name></atom:author>
[...]
<atom:entry>
[...]
</atom:entry>
</atom:feed>
b)
<atom:feed>
[...]
<atom:entry>
<atom:author><atom:name>David Powell</atom:name></atom:author>
[...]
</atom:entry>
</atom:feed>
The same inheritance also applies to some other elements such as
atom:rights, and xml:base/lang suffer similar issues.
Superficially it seems that there is a problem with IE7s rendering, in
that <http://www.tbray.org/ongoing/ongoing.atom> doesn't display Tim
Bray's name next to the entries.
But, actually the problem is deeper than that. Because you only
preserve the latest instance of feed metadata, if it was up to the
client of the API to examine the feed author, and manually inherit it
every time it wanted to display the author of the entry, then the
entry would inherit the wrong authors if the feed author had been
changed since the entry was polled.
Eg: feed producing code may put atom:author only on the feed unless
there are multiple entries in the feed with different authors when it
would add it to the entries too.
Basically you can't require the client of the API (eg IE7) to perform
the inheritance, because they need to inherit the author from the feed
document as it was when the entry appeared in it, not as it is now.
The solution, I expect, is to copy any elements that should inherit
down into the entry during the normalisation process. That way the
display of Tim's feed gets fixed, clients don't need to worry about
inheritance, and author and rights attributions of old entries don't
get mangled by future modifications to the feed document.
Ideally you should perform inheritance from atom:source too, as
described in the RFC.
> 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
I think it is perfectly reasonable to discard "undefined content"
(such as namespaced attributes on Atom elements). If you want an
extension, use an extension element. If you want to sprinkle
attributes everywhere in the assumption that implementations are going
to preserve whatever document you pass to them verbatim - well, don't
be too disappointed.
> * any extended usage of xml:base and xml:lang
Proper preservation of these two is essential. In particular the
baseURI for each feed needs to be preserved after resolving it
relative to the document URI (and Content-Location if you're after
extra credit); the baseURI for each entry needs to be preserved after
resolving it relative to the baseURI for the feed.
The baseURI for entries needs to be stored independently of the feed
metadata, otherwise redirecting the feed, or changing its base, will
retroactively break the baseURIs of older entries.
> atom:published
atom:published isn't preserved as an exact copy. It is converted to an
RSS style date (with the time as-is, and the timezone set to GMT even
if it wasn't).
> Overall it seems to me the MS/RSS team has done a pretty fantastic> job of ensuringa 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 formatand still> maintainany hope whatsoever of making the round trip back to its
> original Atom format.
Here here! With all of the high-profile coverage of RSS in the
publicity, I was expecting Atom to be either neglected, or supported
with much lower fidelity than it is now.
Most of the data-loss problems are minor (and therefore easy to fix
:). The serious problems are with inheritance (xml:base, xml:lang,
atom:author, and atom:rights).
--
Dave
--
<M:D/>
M. David Peterson
http://www.xsltblog.com/
--
<M:D/>
M. David Peterson
http://www.xsltblog.com/
