Właśnie kończę pisać czytnik RSSów do serwisu stylio.pl i pod sam koniec stwierdziłem że przedstawię pewną konkluzję na temat jednego z moich ulubionych słów kompatybilność.
ATOM wg. definicji powstało aby zapewnić pewną kompatybilność. Jednak jak zwykle twórcy wzięli wszystko ze złej strony. Zamiast napisać coś co sprawi że wszelkie główne problemy zostaną rozwiązane , znów zrobili coś co pozwala na wiele “workaroundów”.
Główny problem to oddzielenie treści od formatowania. Żaden z formatów nie wymusza aby dany item posiadał tag z niesformatowanym tekstem. Atom jedynie pozwala na definiowanie contentu. Tak więc możemy stwierdzić czy dostaniemy czysty tekst , czy to będzie zaszyty XML, czy też HTML. Jednak nie ma wymuszenia by każdy wpis posiadał swoją czystą formę, a to moim zdaniem największy problem w robieniu czystego ładnego parsera ATOM-a.
Kolejny problemem który już specyfikacja jednego i drugiego też przewiduje jest zawartość multimedialna. Na listę 10 przykładowych blogów które dostałem tylko jeden posiadał spis multimediów i ich linki eleganckie do sparsowania, jednak w samym opisie oczywiście były tagi <img>.
Ogólnie Twórcy jednego jak i drugiego kanału informacyjnego nie pomyśleli o tym że jego głównym zastosowaniem ma być prostota parsowania poprzez zewnętrzne aplikacje. Niech ktoś mnie poprawi jeśli założenie było inne.
Jeśli by stworzyć kanał który zawsze wymusza czysty niesformatowany tekst, daty publikacji/modyfikacji podawane w czasie UNIX (oraz timezone 0h), listę multimediów użytych w wpisie to wtedy było by to naprawdę super przenośne i każdy by mógł to używać jak mu się podoba, a nie pisać parser do parsera 
