Robert Sayre wrote:
So, you're looking for a way to include a "schema" association in the feed, and you want a standard way to do it. The only processors that will do anything useful with this information are those that know about the "profile".
<feed ...> <head> <ex:MyPetSchema>GottaHaveCategories</ex:MyPetSchema> </head> ... </feed>
You're using Atom, and processors who know about your additional requirements will know about your schema. What you're asking is for the spec to lend weight to your extensions, and I'm not very positive about that.
The problem is that switching on the content of an element/attribute is Atom's get out of jail card wrt extensibility. It is the default Atom extensibility model, as it's the only game we have to play that doesn't involve screwing about with the meaning of existing core data items or adding new core items. Allowing people to add elements in other namespaces under atom:feed or atom:entry and calling that extensibility is like saying a new carpet in my living room is an extension to my house - it's a crashingly weak approach.
It seems to me then that if there's room for believing that there is a set of potential switches, there is room for discussing a core element/attribute to paste them into.
The same argument you make against @profile can be made about @rel. Indeed you could do all this profiling stuff with a new range of values and allowing @rel on the atom:feed element, or less obvious, into the atom:feed/atom:[EMAIL PROTECTED] part. Either of which I think I'd prefer - as we only have extensibility approach it doesn't add value of comprehension to call its slot by two different names.
cheers Bill
