Bruce D'Arcus wrote: >> RDFa includes namespacing, the lack of which is already a problem in microformats (witness hCite and the serious awkwardness that title will be indicate using fn), and which will grow over time as more and more people want to mark up their content. >> Moreover, the need to write dedicate code for each new microformat will also present serious scalability problems. >> Finally, that there's no model at the heart of microformats with clear extension rules means that the vaunted social process here is a mess. >> It's all centralized, and people get frustrated when their pet property isn't included because they know what that means: the tools written for the blessed microformats won't see them.
I agree with your comments. Whereas I think XML namespaces are too difficult for widespread adoption in HTML markup, I think the lack of any similar scope mechanism for Microformats and the resistance of some in the Microformat to prepare Microformats for scaling in usage and application mean that Microformats may end up being remembered as "a good idea at the time" but quite possibly not in use several years out. Scott Reynen wrote: >> I think it's just a limited goal of solving specific problems as simply as possible. If people want to solve general problems without the constraints of keeping it simple for publishers, I'd say they should do that somewhere else. I think you are creating a false dichotomy. I do agree that RDF is too difficult, but I don't think addressing the issues in another way would necessarily sacrifice ease of use. David Janes wrote: >> The best part about microformats (IMHO) is not the class and rel and abbr stuff, but the fact that it deliberately constrains itself to real problems that people are actually having. But only those real problems, as Bruce pointed out, that "conform to some limited set of terms that only get agreed to through some tortuous process of which the vast majority of people couldn't be bothered." Benjamin West wrote: >> Talk of general microformats doesn't make sense. Talk of microformats as technique also does not make sense. If that is true, then having Microformat Design Patterns[1] doesn't make sense. Which is it? The core problem is no strategies have been adopted to avoid naming collisions, and to avoid having the whole concept self destruct from it's own weight of complexity. People who want to contribute but can't because the centralized Microformat community is not interested will go off and create their own and names start clashing, we'll just be left with one big mess. Most of the Microformat community seems to want to keep Microformats a tight knit club focused on a small number of use cases that reviews and approves everything, declining things they don't like, but I think there is really an obligation to the Internet at large to address how to scale the process because Microformats squat on a scare resource (names in classes.) With great power comes great responsibility; Microformats has a responsibility to the web at large to ensure Microformats can scale, but all I've seen is resistence to even consider that (which is one of the reason's I've been quiet lately.) -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ [1] http://microformats.org/wiki/Main_Page#Design_Patterns _______________________________________________ microformats-discuss mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-discuss
