There's been some confusion about the role of the advisory board. The purpose of this post to try to clear it up.
1. It's got a very conservative mission, to answer questions about RSS, to help people use it, to promote its use. It's basically a support function.
2. Anyone can extend RSS through namespaces. We suggest that people look first to see if there is a core element that already does what they need to do, and if so, use that instead of inventing a new one. That will keep the work of aggregator developers to a minimum, keep the barriers to entry low, help keep the market competitive. Competition should be based on features, performance and price, not compatibility. Compatibility should be easy.
3. Emphatically, this group is not a standards organization. It does not own RSS, or the spec, it has no more or less authority than any other group of people who wish to promote RSS.
Comments
It's good to get some documentation up on this. Maybe you could go further and deal with how these policies and mission statements are proposed, debated, and decided on, and how members are chosen (there is the perception that the membership is Dave plus whoever he offers membership to who accepts)
Item number (2) of the referenced post says that "Anyone can extend RSS through namespaces". Besides the warnings already included, you should also mention that doing so means the resulting RSS format will only be well-formed with respect to their own DTD/schema, and, since it will not be well formed under the core RSS 2.0 specification, will probably require a pre-transformation to a well-formed format before it can be successfully used in any transformations for input. (Actually, it seems the 2.0 spec just barely implies what constitutes a well-formed document, which may be understandable given that (3) of the referenced post says "this group ... does not own RSS or the spec [and] has no more or less authority than any other group ...".) As an example, I am trying to develop the mapping (a version of the "DTD", or more appropriately "schema", compiled from source coded in Java in this case) that drives the transformation from a particular extended RSS 2.0 format (feedster.com) to Java objects. The mappings for RDF-based RSS 1.0 were fairly easy to develop, but this particular one's giving me quite a bit of trouble. In this case it seems like the creators of the RSS file thought "If I include the namespace declarations, then I can use any elements from those namespace that I want", not really understanding how namespaced elements in XML are supposed to work in transformations. Maybe they've only used transformations to output their RSS documents (via XSL stylesheets, for example) and never tried to actually read one using transformations. Since the transformer will "complain" if the document being transformed (being read in this case) is not well formed according to the coded "DTD"/schema, I need to include all valid elements (implied by the RSS file in this case, since I was unable to find an actual DTD or XSD) in the static schema definition (but, fortunately, not necessarily in the object itself as well). As a result of their "misuse" of namespaces, I'm probably going to wind up creating a stylesheet to transform extract the valid elements from any extended RSS 2.0 format document into a well-formed RSS 1.0 document and then, when a user clicks on a link to an RSS document, pre-transform it and read in the RSS 1.0 version, since that's already working fine. I had hoped not to do it that way, since my transformer is flexible enough to set the schema based on the root element namespace/name and attributes (usually "version"), and therefore determine "on the fly" whether a particular file contains an RSS 0.91/2.0 or RDF-based 1.0 document, but unfortunately, in RSS documents that have extensions like theirs, the root element does not provide enough information to alert the transformer to expect all of the extra stuff.
