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

[Manu Sporny]

Martin, to start off - thanks for updating your hAudio examples page...
even though you have issues with the proposal. Personally, I feel that
the XHTML is much cleaner now and accomplishes all of the goals listed
in the grouping-examples page. However, it would be foolish to press
ahead if there are still very strong opinions against grouping in
Microformats, or option #3.

Martin McEvoy wrote:
> Sounds trivial but I have to ask, if the method you have proposed is
> just for identification then why use "." as a separator when you know
> what you intend will meet disapproval from many users and developers

I don't fully understand the point you are making. You have mentioned
your aversion to using '.' as a separator. What separator should we use?
 Or is it the fact that we are using a separator that bothers you?
Please be more specific.

You have also asserted several things that I'm having a hard time
understanding:

> Microformats, particularly when one of the first things you will ever
> read about mF is...
> 
> "simple conventions for embedding semantic markup"

What is not a "simple convention for embedding semantic markup" about
option #3? Are you worried about complexities that might arise out of
mixing this markup with other forms of markup? If so, what complexities
do you see?

> "using brief, descriptive class names"

hset is a brief descriptive class name, isn't it?

> "namespaces for content are considered harmful"
> 
> and 
> 
> "If you want to carry on a theoretical discussion of namespaces, please
> do so elsewhere, for in practice, discussing them is a waste of time,
> and off-topic for microformats lists."

We are not talking about name space markup. We are talking about object
identification. I think you are mis-understanding what that page is
talking about.

Name space markup is this:

<mynamespace>
   <problem_statement>The problem with namespaces, is that everybody can
invent their own namespace.
   </problem_statement>
   <problem_explanation>This is not a problem when dealing with a local
name space, such as variables inside a function in a functional
programming language. However, inventing your own namespace becomes a
problem when you want your data to interoperate with somebody elses
data. The name spaces must be mapped to one another and in most cases
this is very difficult.
   </problem_explanation>
   <problem_solution>Microformats steer clear of name spaces for a very
good reason. Microformats are a universal markup mechanism and thus
cannot have anybody inventing tags/elements when they feel like it.
However, this is not to be confused with the way we identify information
in Microformats.
   </problem_solution>
</mynamespace>

Object Identification markup is this:

hset.object_id

Object identification as it relates to hSet is always local to the page.
It doesn't matter what the identification string is, all of these are
equivalent groups:

hset.a
hset.a.b
hset.a.3

hset.1
hset.1.2
hset.1.c

hset.foo
hset.foo.bar
hset.foo.baz

To humans and to a parser, the relationship graph mentioned above is the
exact same thing. We are only talking about IDs and relationships
between the IDs. This is not true if we were talking about a name space:

<a>
 <b></b>
 <3></3>
</a>

<1>
 <2></2>
 <c></c>
</1>

<foo>
 <bar></bar>
 <baz></baz>
</foo>

The name spaces and thus the structure of the documents listed above are
definitely not the same.

Don't confuse name spaces with the grouping problem - they are very
different from each other.

> I don't think grouping is an issue for hAudio, or hVideo and hImage, as
> I believe this feature firmly belongs with hMedia the container or
> transport for any media related mF's

You are correct. Grouping isn't an issue for hAudio. Grouping is an
issue for hSet.

It just so happens that hAudio needs hSet to express relationships that
are needed by hAudio (such as album/track and podcast/clip). With the
current proposal, we won't need an hMedia container format. One less
Microformat is good. Plus, hSet will be applicable to any other grouping
discussion.

> I believe hAudio and any descendants should more resemble a vCard that
> can be sprinkled in to hMedia or any other mF's for that matter.

It currently does, and it will. hSet will not affect hAudio's ability to
be mixed into other Microformats. I don't know if I'm missing something
obvious here... please let us know if there is a reason that using hSet
would not allow us to use hAudio in the same way hCard is used.

-- manu