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

[Manu Sporny]

Chris Griego wrote:
> With my proposal for hSet:
> 
> <h1><span id="internal-event" class="hset vcalendar">Internal</span>
> and <span id="with-client-event" class="hset
> vcalendar">With-Client</span> Events</h1>
> <ol>
> <li class="with-client-event vevent"><span class="summary">FOO Sales
> Pitch</span> [...]</li>
> <li class="internal-event vevent"><span class="summary">Company
> Picnic</span> [...]</li>
> <li class="with-client-event vevent"><span class="summary">BAR Photo
> Shoot</span> [...]</li>
> </ol>

Chris,

What you have proposed is definitely a work-able solution. I've added it
as option #7 in the brainstorming section of the page:

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

There are a few things working against your proposal that I can see (the
option #3 problem solution proposal doesn't have any of these issues):

1. It uses IDs - something Microformats want to avoid.
2. It splits the specification of a set into two parts.
3. It is impossible to define two top-level sets.
4. It mixes identifiers and class names.
5. It is more complex and requires a greater cognitive load on the
   XHTML author.

Here's a bit more detail:

Problem: It uses IDs - something Microformats want to avoid (opinion)
---------------------------------------------------------------------

I believe you were absolutely correct in your first argument against
using IDs for relationships and grouping. We have avoided using IDs for
Microformats thus far and there is no reason that this Microformat needs
to start using them. The use of classes allow us to define multiple
microformats per XHTML element. We should stay away from using IDs
unless there is no other alternative. Option #3 provides an alternative
to using IDs.

Problem: It splits the specification of a set into two parts
------------------------------------------------------------

You have split the specification of a set into two parts - the CLASS
part and the ID part. Option #3 does not split the specification into
two parts. This is purely an argument to use a simpler Microformat
option if it exists (which it does: option #3).

Problem: It is impossible to define two top-level sets
------------------------------------------------------

You cannot define two top-level groups for a single element. For
example, a movie series can be a collection of hImage, hVideo and hAudio
markup as well as being the root element for other sets such as a "best
of" series. In other words, your solution can only create one set
relationship per XHTML element on the page. Option #3 allows multiple
specifications of set relationships on a per XHTML element basis. It can
do this because it doesn't use ID and instead uses class. Option #3 is
more flexible than your proposal because it allows the creation of
multiple relationships per XHTML element.

Problem: It mixes identifiers and class names (opinion)
-------------------------------------------------------

It mixes two page-level XHTML name spaces that should probably be kept
separate: ID and CLASS. I don't see any reason we should mix these two
name spaces when we don't have to...

Problem: It requires a greater cognitive load on the XHTML author
-----------------------------------------------------------------

When authoring Microformats, it is hard enough to remember all the
markup. The nice thing is that almost all markup tends to be pretty
localized - when placing semantic hints in the XHTML, you only have to
place them in one location. The problem solution that you have proposed
places the mark-up in two locations. It is also not obvious to anybody
reading the XHTML (yes, people still do this) that the Microformat
described in the class is actually part of a relationship/set/grouping
of some kind.

For these reasons, I believe that Option #3 is still our best bet
because it is the simpler solution. Please debunk as necessary...

-- manu