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

Manu Sporny msporny at digitalbazaar.com
Wed May 23 11:19:37 PDT 2007


Brian Suda wrote:
> On 5/22/07, Manu Sporny <msporny at digitalbazaar.com> wrote:
>> We need a way to create the concept of an audio collection (an album).
>> The same can be said for video and images - how do you relate these
>> items to one another?
> 
> --- i completely agree

Well, at least we agree on that :)

> The Problem statement for your grouping is:
> 
> It is useful to understand the relationship between objects on a
> website. 
> ...
> that is too generic, OBJECTS on a WEBPAGE? for things like Events, we
> needed a container, so a CALENDAR container was created. For ENTRIES
> we created hFeed. These sort of groupings are handled at the format
> level, not a generalized hSet.

We are starting to "solve" this container problem over and over again.
We've already created redundant container/grouping/set mechanisms:

vcalendar for vevents
hfeed for hentry

Where do we go from here?

halbum for haudio
hpodcast for haudio
hfilm for hvideo
hmultimedia for haudio and hvideo combinations
htvseries for hvideo

Every single one of these containers does the exact same thing - it
contains OBJECTS. Why are we calling them different things when they're
really the same thing. Why are we willing to pollute the Microformats
namespace with halbum, hpodcast, hfilm, hmultimedia, and htvshow? They
are just variations on the same theme - grouping.

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'm having a hard time understanding what is so complex about:
>>
>> hset.GROUP_ID.OBJECT_ID
> 
> --- to me this makes no sense? in traditional programing languages the
> dot notation is used for member functions which are usually VERBS. The
> Person Object has a function getName(), Person.getName(). 

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.

C:
--------------------------

void (*operation)();
struct foo
{
   int bar;
   operation do_operation;
}

foo f;
f.bar = 5;
f.do_operation();

C++
--------------------------

class Foo
{
public:
   int bar;
   void doOperation() {};
}

Foo f = new Foo();
f.bar = 5;
f.doOperation();

Python
---------------------------

class foo:
    def __init__(self):
        self.bar = 0

    def do_operation(self):
        pass

f = Foo()
f.bar = 5
f.do_operation()

C#
----------------------------

public class Foo
{
   public int bar;

   public void doOperation() {};
}

f = new Foo()
f.bar = 5;
f.doOperation();

Javascript
----------------------------
class Foo
{
   var bar:Integer = 0;
   function do_operation() {}
}

var f = new Foo();
f.bar = 5;
f.do_operation()

We would be adopting something that has stood the test of time - we
wouldn't be re-inventing the wheel.

> The
> hset.GROUP_ID.OBJECT_ID tells me nothing.... not even XML or RDF or
> other mark-up languages use this? everything is done by nesting an
> OBEJCT_ID in a GROUP_ID in an hSet.

It tells you one thing - that if something else has the same GROUP_ID,
it belongs to the same group. It tells you that there is a relationship
between two objects.

> --- the simplest solution is just to choose a semantic class value for
> your container, we already have 'vcalendar', 'hfeed', which act in
> this capacity. Those are the simplest solutions, lets start there, and
> itterate.

We did start there. Iteration has brought us to the understanding that
we are going to "solve" this problem over and over again if we don't do
something about it. Increasing the number of container elements will
only pollute the Microformats element space with unnecessary grouping
mechanisms that do the exact same thing.

> We want to make this as easy as possible for publishers, not parsers.
> The vast majority of the people publishing microformats do not have
> PhDs in computer science. We tend to forget that something that seems
> easy for us might be completely over the heads of others.

Using dot notion is not a foreign concept to anybody that has written
CSS. May I remind you that this is a common practice in CSS:

h1.highlight {
   color: yellow;
}

This will make any <h1> element that has a class of 'highlight' to
appear yellow.

If using dot-notation is such a big problem, we could always use a
different character, such as '-' or '_'.

hset_foo
hset_foo_bar
hset_foo_baz-bat

or

hset-foo
hset-foo-bar
hset-foo-baz_bat

or

hset:foo
hset:foo:bar
hset:foo:baz-bat

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.

-- manu



More information about the microformats-new mailing list