- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 07 May 2008 22:14:21 +0200
- To: Ian Hickson <ian@hixie.ch>
- CC: "public-html@w3.org" <public-html@w3.org>
Ian Hickson wrote: >> 1) Conflicts *do* occur, as soon as you consider extensions that happen >> outside the microformats process (and that process seems to exclude >> private extensions, such as for intranet applications). > > Conflicts do not occur on the kind of scale that requires dedicated > markup. Not sure what you mean by "dedicated markup". At the end of the day, this just seems to be another example of the "extensibility based on namespaces" dispute. Some believe in it, some don't. You obviously don't. The question here is: what does the *working group* think? >> 2) As a matter of fact, <http://microformats.org/wiki/profile-uris> states >> >> "In hcalendar-issues, it is ACCEPTED that each microformat should have a >> profile URI, like the XFN profile (http://gmpg.org/xfn/11)." >> >> So it seems you are in disagreement with the microformats community as well. > > Actually the removal of profile="" was done in conjunction with the > Microformats community. I do not know whether that page represents > consensus in that community or not. I have asked for clarififcation. Good. Here's another quote: "microformats use unscoped class names misconception: Microformats definitions use unqualified/scoped class attribute strings as semantic tags. This is incorrect on two counts. First, microformats make use of profile URLs to define class name semantics. Thus it is entirely possible (though both unlikely, and undesirable) for someone to redefine class names with their own definitions in their own profile URL. Second, compound microformats (e.g. hCard, hCalendar, hReview) use a fairly uniquely chosen string for the "root element" (e.g. vcard, vcalendar, vevent, hreview) and then generic terms only inside that root element. Thus use of any generic terms are scoped (some might even say "namespaced") within the fairly uniquely chosen "root element" class name." -- <http://microformats.org/wiki/misconceptions#microformats_use_unscoped_class_names> >> That being said; I agree that the profile attribute is not a good >> solution, as it is of limited use only. Thus, instead of removing it we >> should think about fixing it, or using something that works instead > > Before we think about using something that "works", we have to determine > why what we have now doesn't "work". It isn't at all clear to me that we > have any kind of practical problem here. OK, more input: - <http://www.mikeschinkel.com/blog/enthusiasmformicroformatspremature/> - problems nesting different microformat syntaxes (will have to dig out a URL) So, from my POV, microformats can be a nice approach for some common formats (and that's why I support hCard myself in my code), but they do not scale well. BR, Julian
Received on Wednesday, 7 May 2008 20:15:17 UTC