extension model of RSS/Atom (ISSUE-16 discussion)

hello.

circling back to ISSUE-16 and james' claim that RSS/Atom had simple 
mustIgnore routes and AS2 is doing that already by simply and silently 
relying on JSON's generic extensibility capabilities. this is not really 
how it is.

Atom actually was careful in defining specific extensibility both on the 
schema as well as on the processing level. The schema clearly defines 
where extensions should be expected. Atom uses RELAX NG for that which 
has pretty good capabilities. XSD would have been a different option. 
but either way, Atom *does* explicitly define how producers are allowed 
to add extensions, and how consumers should expect extensions.

at the processing model level, 
http://tools.ietf.org/html/rfc4287#section-6 defines how those 
extensions are to be processed, and what's expected as behavior from 
implementations. Atom even defines a lightweight "infoset" by defining 
atom markup and foreign markup and how they should be treated.

to me, those two components (the well-defined extension model defined in 
RELAX NG and the section on how to process those extensions) are exactly 
what we are missing.

as a historical note: Atom put quite a bit of effort into this because 
RSS was not all that well-defined (whatever version of RSS you're 
talking about), and one lesson of that was that implementations were 
behaving in unpredictable and sometimes unfortunate ways. RSS at that 
time was a huge ecosystem, and i think it would be good to look at the 
lessons learned back then, and make sure we're not doing the same 
mistakes again.

cheers,

dret.

-- 
erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

Received on Tuesday, 7 April 2015 18:06:58 UTC