[uf-new] Revisiting grouping problem solution proposal: hset

[Chris Griego]

I absolutely agree with Brian's sentiment here that the optional
container class names that exist today have very different semantics.
That's why I maintained them in my proposed option[1] while also
trying to avoid the need for any form of namespacing or notation, dot
or otherwise, in the class attribute.

Replacing the existing container class names are a non-problem, but I
recognize that sparse grouping is a problem, which is why I see hSet's
role more as an alternative to the include-pattern, which is a useful
solution (that uses the ID attribute) in many situations, but clunky
at best when dealing with sparse grouping. Case in point is that
Martin's rev-based option is reinvention of the include-pattern with
all of the same clunkiness.

[1] http://microformats.org/wiki/grouping-brainstorming#Option_7:_id-class_grouping

-- 
Chris Griego


On 5/24/07, Brian Suda <brian.suda at gmail.com> wrote:
> On 5/23/07, Manu Sporny <msporny at digitalbazaar.com> wrote:
> > Brian Suda wrote:
> > We are starting to "solve" this container problem over and over again.
> > We've already created redundant container/grouping/set mechanisms:
>
> --- no they are NOT redundant. They have different semantics.
> Microformats are MICRO and they solve a specific problem. If we create
> a generic SET object then what does it mean when you begin to have
> mixed content in that set? some events, some people, some XYZ format.
> This is no longer MICRO but attempts to "boil the ocean" which is
> something we want to avoid.
>
> > Where do we go from here?
> >
> > halbum for haudio
> > hpodcast for haudio
> > hfilm for hvideo
> > hmultimedia for haudio and hvideo combinations
> > htvseries for hvideo
>
> --- if need be, then yes. hpodcast has very different semantics than
> vcalendar. But i am pretty sure that microformats will stay micro, we
> are worrying about a problem that does not exist.