James M Snell wrote:
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?
1) You do realize that there is a [EMAIL PROTECTED] mailing list, don't you. :-)
2) Overall, the reason the feedvalidator is the way it is in this area is (1) to catch mispellings, and (2) to enable people who create internet drafts to safely create new elements and attributes without concern over existing usage. Yes, it does mean that the feed validator needs to be updated as new drafts are published; but that's generally not been a problem.
3) The only reason I said warning in this case is that the I-D isn't yet approved, and the warning will state exactly that. Should it become approved, there would be no warning. Should it expire, the warning would revert back to an error.
4) James and I have had a background conversation going over a long period of time... he has advocated introducing additional subtleties in gradation, and not just limiting things to errors and warnings. In general, I have found that not everybody who runs the feed validator against their feed is as well versed in the spec as people who tend to follow this (atom-syntax) mailing list are, and would be confused. In such cases, simple (it either allowed by an existing spec, or it is not; if allowed, it either generally works interoperably or it doesn't) is better.
- Sam Ruby
