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

[Brian Suda]

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.

> I understand your position, Brian. In general, Microformat grouping
> should be developed on a case-by-case basis.
>
> However, when it is clear that we are going to have to create multiple
> new Microformat elements that do the /exact same thing/ - we should
> start to question if this problem should not be solved in a more general
> way.

--- i disagree, we are back to the issue of trying to solve all
problems at once. Microformats already conceded that they will NEVER
solve every problem, that is the whole point of the 80/20 rule. And
the containers do NOT mean the /exact same thing/ in all contexts.
With hFeed you can attach tags to the hfeed and to entries. With other
formats you might be able to attach a label or other metadata to the
grouping. Each format will be different and therefore requires their
own container value. Not to mention the fact that when you begin to
mix content in a generic container how do parser or publisher explain
what data part of that container and which should be omitted? this no
longer seems MICRO, especially since we already have a solution that
solves these problems, specific container names.

> No, in traditional programming languages, dot notation is used to
> separate package names or object members and methods. It is the de-facto
> method of grouping in most modern programming languages.

--- i'm sorry my simple dot.notation comment fell flat, but i think it
just proves that this proposal is attempting to conflate semantics in
class values with machine instruction about grouping ids, etc. This is
NOT semantics, this is no different than saying "bluebox" or "col134"
those are NOT semantics, they are presentation or instructive. This is
also exactly why avoided encoding things like telephone HOME or WORK
types in the class attribute.

> The suggestion to use '.' was made because it is the most common form of
> denoting group membership, that doesn't mean we're stuck with it.

--- then might i suggest that we just use unique values for unique
formats containers?

This conversation is quickly becoming cyclical. Microformats solve
problems today, not theoretical potential issues. In the last 2 years
the number of microformats that have garnered any major adoptions has
not been astronomical. We are NOT inventing new formats each week,
solving a generic grouping problem is NOT a problem. So lets focus on
the individual formats.

-brian

-- 
brian suda
http://suda.co.uk