Danny Ayers wrote: > Ok, I see what you're getting at. But if those things are in the same > group, then why not group them in the HTML? Let the browser display > the items in the same group in proximity. Humans first and all that.
One of the beautiful aspects of Microformats are that there is very little that is required. Most Internet standards make a differentiation between "MAY", "SHOULD" and "MUST". Microformat rules have very few "MUST"s. What you are proposing is: If you want to performing item grouping in Microformats you "MUST" put the items in very close proximity to one another. That is restrictive. It is a rule that we don't need to impose on anybody as there are several solutions that don't require that rule to exist. The less rules that there are, the more flexible and adaptable the standard. > Do you have any examples of data/markup where this wouldn't be > appropriate? There are at least 80-150 examples on scissorkick.com, here's one of them: http://www.scissorkick.com/2007/03/battles/ In the blog post, the following album and songs are mentioned: Artist: Battles Album : Mirrored Songs : Atlas, Tonto They are not in list format - they are mentioned in free verse at different points in the post. The blog poster (as is with most of the postings) goes to great length to italicize albums and place quotation marks around songs. They have a desire to mark this information up - but don't seem to want to do it using any sort of list mechanism. There are also around 70,000 examples on Bitmunk that have this type of sparse item layout in album descriptions: http://www.bitmunk.com/view/media/6068744 Artist: Celldweller Album : Celldweller (self-titled) Songs : Stay With Me (Unlikely), Switchback, The Last Firstborn, Own Little World, So Sorry to Say, Welcome to the End >> 1. You are creating a 1-1 relationship, not an N-N relationship. URLs >> can only point to a single location, thus they are incapable of >> providing grouping information by themselves. > > Sorry, the WebArch wonk in me grumbles there: URIs name things, links > provide relationships between things. In the example above, grouping > information is provided by the HTML. Also there's no reason links > can't point into a list: > > <ul> > <li><a name="one">one item</a></li> > <li><a name="two">another item</a></li> > </ul> > > <a href="#one" rel="self">item one again</a> > <a href="#two" rel="self">item two again</a> > > - no, I'm not sure about rel="self", but maybe something along these > lines might work. That's not the problem that we are trying to solve. Let me re-state the problem in a different way: You have a group G, and several items (A, B, C, D). Each are mentioned in different places on a web page, not necessarily in any order. How do you specify that A, B, C and D belong to group G? >> 2. You are constraining the site design by forcing the need to use a >> URI. It doesn't give the site designer an option - it's the >> Microformat way or the highway at that point. > > If entities are worth identifying on the web, they should be given > URIs. It's in the site designer's interest for it to be possible to > refer to them from elsewhere on the web. Yes, but there is a big difference between "MUST", "SHOULD" and "MAY". The argument that you proposed states that they "MUST" be identified by URIs to be able to be grouped. > Yes, thanks. > But for these non-local, loose associations, won't you end up with > machine-readable relationships embedded in the markup that aren't > human-readable? I don't personally have a problem with that, but it > does seem to be, er, not very microformatty. Yes, you are correct - we do end up with some machine-readable relationships that are not formatted in list form using HTML. They are, however, human-readable. I'm not saying that partial information hiding is a good thing... but I haven't come across any mechanisms that would allow us to provide N-to-N relationship markup using purely visible HTML. If somebody has a proposal for doing so, please do speak up as Danny and several others have outlined this as an undesirable effect of the proposed methods thus far. -- manu _______________________________________________ microformats-new mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-new
