Brian Suda wrote: > On 5/22/07, Manu Sporny <[EMAIL PROTECTED]> 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 _______________________________________________ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new