On Thu, Nov 26, 2009 at 1:56 PM, Fiann O'Hagan <fia...@jshub.org> wrote: >> I agree, this seems much more in line with RDFa than microformats. To do >> this in microformats, we'd need to throw out the visible data requirement, >> and re-interpret all of the other guidelines to no longer presume visible >> data. And after a lot of work, the result would end up looking a lot like >> RDFa. > > Why would it end up looking like RDFa? This is the part I don't > understand. RDFa looks like it does because it involves XML > namespaces, namespaced values for XML attributes, and URIs. The markup > indicates relations between items, where the nature of the relation is > defined by resolving a URI.
Agreed. In practical use cases for marking up visible data, namespaces, bound prefixes etc. have never been necessary. It appears the desire for abstract bound (or literal) prefix namespaces (often strongly outspoken, especially on email lists - see recent mega-threads at public-html at w3.org for example) is primarily religious/dogmatic/tautological in nature rather than based on real world use cases. This is one of the key reasons why their discussion is explicitly discouraged on microformats mailing lists, and I'll leave it at that. http://microformats.org/wiki/mailing-lists#Bad_topics_for_discussion > In contrast, microformats simply use some well known class names. Well, that plus they've gone through a fairly rigorous development process: http://microformats.org/wiki/process > If we have an element with the class of hproduct, it describes a product. > Inside that, an element with the class of fn is the product name. > There is no URI to dereference to understand what is meant by fn. There is no URI that you *MUST* dereference to understand what is meant by fn, but for example if you are using hCard, you *MAY* reference the hCard profile and thus place the "fn" term in URI space: http://microformats.org/profile/hcard#fn This is allowed by microformats, because it helps with interop with some other technologies. It's optional because in the vast majority of practical uses, it's unnecessary. > ... I was imaging something much simpler, > which looks like any other microformat, but with some or all of the > content in a CSS display:none region of the page. That to me still > looks like a microformat, not like RDFa. As Scott has pointed out, it will be nearly impossible to make a microformat for invisible data given that the process has many steps requiring documentation/existence of visible data to mark up. However, what you're talking about, simple use of class names that "looks like any other microformat" is actually poshformats: http://microformats.org/wiki/poshformats It's an important distinction, take a look. For your original use case that you mentioned, invisible data for scripts/script libraries, you have a couple of choices: 1. make up a poshformat and take care to NOT call it a microformat (because it isn't one, and you never intend to try to take it through the process) 2. use the "data-*" attributes in HTML5 which were explicitly created to handle the use case of data attributes for scripts/script libraries among other things. http://microformats.org/wiki/html5#data_attributes If you're comfortable with starting to use HTML5, I recommend the latter option, because it better reflects your use case, and hopefully will have less chance of implying there is a format of data to interchange when there isn't. Thanks, Tantek -- http://tantek.com/ _______________________________________________ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new