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, but this is an issue on a format, by format basis. The Problem statement for your grouping is: It is useful to understand the relationship between objects on a website. A blogger may want to describe several different objects on a web page and group them explicitly. It is important that the structure of the page not affect this grouping as network relationships are often not hierarchical (HTML is always hierarchical). 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. If you want to solve the problem of grouping Audio, then lets solve THAT problem. If you want to group Media, then lets talk about that. Not a general hSet to "understand the relationship between objects on a website"
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(). 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 seems like a very simple solution - Brian, Tantek, please take some time to explain your position. Or in the very least, include a link to where your arguments and position have been explained before.
--- 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. If for some reason something like an hMedia class cannot solve your issues, then we can begin to look into other solutions to convey the needed semantics (or discover if there really is a problem or identifing objects and groups). 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. -brian -- brian suda http://suda.co.uk _______________________________________________ microformats-new mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-new
