In the current draft we have two types of Collections, Generic+1
and Entry. We know that we would like other types of Collections, whether they are defined in this spec or another, we know that we want them.
I think this is fine so long as it's not limited to HTML content. The definition of the @class value should determine the @type of content. For instance, I should be able create a class that requires XML content, or binary content, etc.The two Collections, Generic and Entry, are the most general types of collections we would want. Any other type of collection is just going to be a subclass of either 'generic' or 'entries'. That is, a collection that just accepted images would just be a subclass of 'generic'. A collection of Book or Music entries would just be a subclass of 'entries'. <snip /> The solution, of course, is microformats. To subclass an Entry Collection you declare what type of microformat must be in the HTML of the entry:content. Yeah, it's just that simple.
As is the case with the @rel values, would it be possible to use non-IANA registered fully qualified URI's?Now the 'class' attribute maps to a IETF registry via a URI in a manner similar to the 'rel' values for the link element. That registry defines "http://...some-ietf-regisgtry-name.../movies"; to be a Collection that only accepts entries that contain hReview's of movies. That unique URI we'll call the Collection Subclass URI.