Eric Scheid wrote:
I just had a thought (astounding!)
If we remove the version attribute and change the namespace only when there is a backwards incompatible spec revision, and assume mustIgnore for unrecognised elements from any minor version updates ... then this leaves the door open for someone to produce feeds with any ad hoc element, even elements which are not in any updated Atom specification.
How would a feed validator react to something like this:
<feed xmlns="http://purl.org/atom/ns#1.0";> <head>...</head> <entry> <foo>...</foo> ... </entry> </feed>
It can't say <foo> isn't allowed in this feed, because it doesn't know if <foo> was introduced in Atom 1.1. If the validator is updated to know about Atom 1.1, the same problem exists: it doesn't know if it came from 1.2.
One of the criticisms I've seen for OPML is that anyone can add any element or attribution of their own invention anywhere any time, and that this has led to xml-soup.
Do we want to see the same future for Atom?
Whether the feedvalidator flags such an element or not, the spec declares (or will declare once the spec is updated to reflect the last round from the workgroup) such elements as invalid.
Furthermore, having things like the feedvalidator flag unknown elements in the Atom namespace as invalid is exactly what makes it safe for future authors or revisions of the Atom specification to add new elements in the Atom namespace without fear of conflicting with existing feeds.
What this does mean is that the feedvalidator either needs to be updated when new versions of Atom come out, or become increasingly irrelevant and obsolete as new validators assume this role (possibly something as simple as a RelaxNG schema).
- Sam Ruby
