2007/10/15, James M Snell: > > Sam's position (which he can correct if I have misstated anything) is > that the validator should take a strict approach and mark all unknown, > non-namespaced attributes as an error unless there is a known > specification that is specifically updating RFC4287, as is the case with > the Bidi draft. > > I wanted to see what others thought about this. How should such > extensions be treated? What if someone wanted to come along and invent > a new element in the atom namespace, e.g. <atom:foo />. What should the > validator do? Ignore it? Signal an error?
Section 6.3 defines error-recovery, it does not mean however that "unrecognized markup from the Atom vocabulary" is not an error. Validators should throw an error for those attributes and elements "from the Atom vocabulary" that hasn't been defined in RFC4287 or another I-D. I don't know what the current behavior is, but I think the feedvalidator (or any other Atom validator, if any) should also signal warnings for non-Atom-namespaced markup (markup from other vocabularies) that are not "known extensions" (iTunes, GeoRSS, etc.) IMO, validators should, in addition, link to the specs of the extensions used by the feed. For instance (once the dir= I-D is approved), it shouldn't throw an error or signal a warning when the dir= attribute is (correctly) used, but it could say "this feed uses the RFCxxxx extension" with the appropriate link. -- Thomas Broyer
