On 5/23/07, Manu Sporny <[EMAIL PROTECTED]> 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 _______________________________________________ microformats-new mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-new
