Re: Development of uFs outside the current framework (was: microformats vs. semantic XHTML (was Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats))
Am Donnerstag, 14. Dezember 2006 20:41 schrieb Andy Mabbett: What if ... many what if :) Well, quite. And there's more than one. Sure. And why not. And there are already publications out there which are quite old, published long before the term microformats was invented, and which nevertheless is a proposal for the same purpose: Encouraging semantic markup. I do remember a work of someone, iif i recall right, named Randall Trigg, who already defined relation types in the nineties. Although his relations where not between persons, but between web documents. A very interesting work. I currently do not have the url, but googling for it should work. Or think of the several effords for link relations regarding types like next, prev, contents and the like. Already the w3c suggested some. I've put together a crude page resuming those, plus some reference links: http://www.rorkvell.de/tech/stdnav In this context, microformats may be considered to be something like a brand. Like hoover or biro..? I don't know these :) Well, to make it clear, think of semantic markup as cigarettes. Then microformats is something like Marlboro. That's a brand. You can invent any cigarette type you want, but it will never be Marlboro, if not branded by that company. Regards Siegfried ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats
Scott Reynen wrote: This mirrors how natural language works. Until there is some need for clarification, we assume everyone knows what we mean. Then there is a need for clarification, we clarify. No one goes around defining every word before they use it, and I don't think we can expect publishers to behave differently with HTML symbols. We could require profile URIs, but that won't make anyone use them. OI think only a practical need for disambiguation will do that. The analogy is flawed. Humans have intelligences to compensate when presented with ambiguity. Machine (at least currently) do not. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: URI profiles [was RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats]
In message [EMAIL PROTECTED], Elias Torres [EMAIL PROTECTED] writes 2) Rather than having a profile for each uF (and, presumably, near-duplicate profiles for nested uFs such as geo or adr in hCard?) why not have one over-arching profile for all microformats? Funny you say that since it's one of the biggest misconception of Semantic Web ideas. That SW seeks to find a single ontology for all of the data in the world. bleech. Were I suggesting what you seem to think I'm suggesting, your bleech would be appropriate. I'm glad we are in sync then :) What were you really suggesting? One over-arching profile for all microformats. -- Andy Mabbett * Say NO! to compulsory ID Cards: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: the term microformat and encouraging people to play (wasRe:[uf-discuss] Comments from IBM/Lotus rep about Microformats)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On S. Sriram wrote What you have is a 'classic branding problem' ... Excellent analysis. Al Ries is my hero. :) -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Development of uFs outside the current framework (was: microformats vs. semantic XHTML (was Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats))
In message [EMAIL PROTECTED], Siegfried Gipp [EMAIL PROTECTED] writes Take f.ex. one of my pages: http://www.rorkvell.de/tech/dc This is a page which aims to combine the ideas of microformats with the Dublin Core vocabulary. This is by definition _no_ microformat, since this did not go through any process other than my own thoughts. But it is semantic markup and it is somewhat similar to microformats, it even sports an XMDP profile. But still it is _no_ microformat. What if it takes off, and is adopted by many publishers and parsers (let's say they include the Dublin Core body, and Google, respectively), with many millions of examples on-line. Will it be a uF then? If not, why not? To convert that to a microformat that proposal would have to go through the microformats process. What if it when through that process, not on this mailing list related 'wiki', but, say, those belonging to the Dublin Core body? What if that happened, but the process was a little different? Say 5% different? Or 10%? Or..? What if many such pseudo-uFs did the same, past the point where those developed here were less than the (sacred) 20% of those widely in use? Simply a matter of definition. Well, quite. And there's more than one. In this context, microformats may be considered to be something like a brand. Like hoover or biro..? -- Andy Mabbett * Say NO! to compulsory ID Cards: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: URI profiles [was RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats]
On 12/14/06, Andy Mabbett [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Elias Torres [EMAIL PROTECTED] writes 2) Rather than having a profile for each uF (and, presumably, near-duplicate profiles for nested uFs such as geo or adr in hCard?) why not have one over-arching profile for all microformats? Funny you say that since it's one of the biggest misconception of Semantic Web ideas. That SW seeks to find a single ontology for all of the data in the world. bleech. Were I suggesting what you seem to think I'm suggesting, your bleech would be appropriate. I'm glad we are in sync then :) What were you really suggesting? -- Andy Mabbett * Say NO! to compulsory ID Cards: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: the term microformat and encouraging people to play (was Re:[uf-discuss] Comments from IBM/Lotus rep about Microformats)
Am Dienstag, 12. Dezember 2006 20:16 schrieb Tantek Çelik: microformats is the specific brand (your term) of semantic (X)HTML that follows the microformats principles and process. You could say that RDFa is another brand of semantic (X)HTML that follows its own principles. Just to be complete: Simply to use the html elements for what they where designed for is at least the first step to semantic (x)html. Even more important than microformats and RDFa. If used properly, any single bit of html markup _is_ semantic markup. And, last not least, the rdf and owl effords of the w3c is semantic web, too, although it has nothing to do with (x)html. But well, the web is not identical to (x)html! regards Siegfried ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Upper and lower case microformats (was: [uf-discuss] Comments from IBM/Lotus rep about Microformats)
Am Dienstag, 12. Dezember 2006 23:29 schrieb Andy Mabbett: In message [EMAIL PROTECTED], Mike Schinkel [EMAIL PROTECTED] writes lowercase microformats = unofficial semantic markup embedded in HTML uppercase microformats = Official Microformat Does: HTML is good. Microformats are wonderful refer to the former, or the latter? Although this statement is correct, it does neither refer to the former nor to the latter, because both are nonsense :) regards Siegfried ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: URI profiles [was RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats]
On Dec 13, 2006, at 1:40 AM, Joe Andrieu wrote: Making people use them is not the same as clarifying in a spec what should be done, must be done, and what is optional. If we are specifying that parsers can ignore non-profiled semantic HTML that looks like microformats, we are essentially saying parsers can ignore non-profiled microformats, since you can't tell the difference. Which means that URI profiles are /effectively/ required if you want to be assured that standards-compliant parsers will pick them up your microformats. Yea! I think profiles are great. So, why not formalize the requirement? So profile URIs are described here: http://microformats.org/wiki/profile-uris where it says: it is ACCEPTED that each microformat should have a profile URI. I agree it would help to make that more clear, but if you're suggesting we change that should to a must, I'd ask you what practical benefit you expect publishers would gain from such a change. We're trying to avoid solving hypothetical problems here, and I don't see a practical problem profile URIs solve yet, as I haven't noticed anyone using class=vcard to designate their Valentine's Day cards or anything else other than hCard. If you're interested in seeing wider adoption of profile URIs, I'd recommend work on filling in the XMDPs for every microformat, because it wouldn't make much sense to require publishers to point to profiles which don't exist. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: URI profiles [was RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats]
In message [EMAIL PROTECTED], Joe Andrieu [EMAIL PROTECTED] writes Which means that URI profiles are /effectively/ required if you want to be assured that standards-compliant parsers will pick them up your microformats. Yea! I think profiles are great. So, why not formalize the requirement? 1) If profiles are mandatory (or implicitly required by p*rser behaviour), what happens to people who cannot edit the head element (blog or CMS users, for instance)? 2) Rather than having a profile for each uF (and, presumably, near-duplicate profiles for nested uFs such as geo or adr in hCard?) why not have one over-arching profile for all microformats? -- Andy Mabbett * Say NO! to compulsory ID Cards: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
Mike Schinkel wrote: If it is not a scarce resource, please tell me what would happen if I decided to start marking up documents, as an example, using the class directory and license, for purposes other than rel-directory and re-license? How could my markup and those Microformats co-exist in the same HTML document? --- This hasn't been a problem yet, but we do have mechanisms to prevent problems in this space. It is possible for me to start creating a CSS style called 'vcard', but a parser would know that this is a style and not semantics because of the lack of a profile URI. Eventually, as microformats become more popular, the profile URI is used to disambiguate random styles with intended semantic values. So far this isn't a problem, and to save time and effort we are focusing on the more important things. (IMHO) i would like to see more profile attributes, but i am not too worried - we'll cross that bridge when we need too, but there is a system in place to solve these problems - microformats are not squatting on terms. -brian ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
the term microformat and encouraging people to play (was Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats)
On 12/11/06 10:20 PM, Håkon Wium Lie [EMAIL PROTECTED] wrote: Thanks for chiming in Håkon - your opinion is always appreciated. Also sprach Mike Schinkel: I'm not quite sure what you mean here. Is there a difference between lowercase microformats and uppercase microformats? lowercase microformats = unofficial semantic markup embedded in HTML uppercase microformats = Official Microformat This makes sense to me. Preventing people from using the term microformat for their own set of class names is an uphill battle; It is perhaps, but it is quite similar to the battle that W3C has fought with use of the term HTML, which, as we both know, was subverted by various vendors etc. during the Browser Wars of the 1990s to mean *their* variant of HTML. Through the hard work of W3C, and advocate organizations like the Web Standards Project (WaSP), that subversion was largely successfully fought and overcome, and popular notion accepts that HTML is what W3C has defines it to be (HTML 4.01, XHTML 1.0). Just as with that uphill battle which was eventually won (except for a few web designers stuck in 1990s-think who think HTML means what works in IE, ahem, *which* IE? :), it is worth fighting this battle to ensure that microformats keeps its meaning above and beyond semantic (X)HTML. (Sidenote: ironically, W3C squandered this long fought for victory of what is HTML with the sadness that is XHTML 2.0 which itself inspired/forced the creation of WHATWG and HTML5 efforts, as well as microformats, but that's another thread that an entire other mailing list is handling as you and I both know.) the term microformat is simply too attractive. It's interesting, because I couldn't have predicted this. There was an even earlier term microcontent which hinted at some of the same use cases, which however, unfortunately didn't have a precise definition (nor any definition really) that anyone used consistently (everyone used it to mean their pet thing), and thus because its meaning was never clear, its usage became quite diluted and worthless. One of the reasons that I explicitly set about documenting the microformats principles and process very early on in the evolution of microformats was to avoid what happened with microcontent. This isn't finished. We must continue to insist on a reasonably precise meaningful definition or else the concept itself will become meaningless (or perhaps worse, subverted by major vendors (though the names might be different this time around) as was attempted with HTML). Besides, people should be encouraged to play. Agreed - with some clear criticisms when they play for the wrong reasons, or in a bad way. For example there are people who invent their own microformats (as they incorrectly call them) who can't even be bothered to publish valid XHTML. If you cannot follow existing standards, how can you possibly expect *anyone* to follow yours? There are also people that are under the mistaken assumption that a microformat they create is for their personal use. I'm not naming names. The point of a standard format is interoperability *between* *different* parties. I'll take that a step further and say that if at least *two* other people (whom you are unrelated to etc.) are not interested in sharing information with each other (i.e. not just you) via your microformat proposal besides you, then stop - you have no microformat. Just document (i.e. blog) your own personal use of semantic (X)HTML in the hopes that if someone comes along later and wants to do something similar, they *may* mimic your work. Most private sets will quickly die a natural death and do no harm. Those who survive in the wild deserve the capital M. See previous email from me on microformats vs. semantic XHTML first. I strongly encourage people to experiment and document their uses of semantic XHTML. In fact, if you read popular modern web designer blogs, they have been doing this (not just *talking* about it) for *years*. [1] If you want to participate in helping *others* interoperate (not just yourself) and believe you have found a common publishing behavior on the web that can benefit from greater interoperability, then by all means, follow the microformats principles and process and develop a microformat to do so. And those of you that *do* wish to develop microformats, I strongly recommend you subscribe to and read popular modern web designer blogs, as they are the ones who have the most experience with semantic XHTML (far more than anyone in the XML/RDF communities), and they are who you should be reading to understand where microformats came from and how to improve the fidelity of your web publishing in general. [1] Thanks, Tantek [1] In no particular order here are a few (and apologies in advance to those I know I am forgetting this early Tuesday morning with this hastily created list mostly off the top of my mind, and make sure your site validates ;) http://zeldman.com/
microformats vs. semantic XHTML (was Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats)
Mike, Ben, a gentle reminder, please update the subject line when the subject changes :) On 12/11/06 8:45 PM, Benjamin West [EMAIL PROTECTED] wrote: On 12/11/06, Mike Schinkel [EMAIL PROTECTED] wrote: Benjamin West wrote: I'm not quite sure what you mean here. Is there a difference between lowercase microformats and uppercase microformats? lowercase microformats = unofficial semantic markup embedded in HTML uppercase microformats = Official Microformat That's the first I've heard of this usage. Same here. I think what I'm hearing (and agree with) is a need for a term that describes the product of semantic markup techniques in a general way. Lots of people are already doing this, and don't need any official body to bless them. semantic XHTML (OR semantic HTML) This is well-used well-adopted pre-existing term and there is no need to invent a new term to mean the same thing. Microformats (any casing) would be a subset of these products that are blessed by pervasive use across the web. I'm hesitant to pick out such a name, lest I choose badly (eg AJAX). I'm happy to let the market pick that name (eg I don't think anyone should deliberately pick it out.), but at the same time, I'm hesitant to let the term microformats be applied to general applications of general techniques. I'm frankly not ok with this. This is one of the reasons why I have avoided capitalizing the term microformats everywhere it is used. There is no capital variant. There is just microformats, as has been defined. And just as squares are quadrilaterals with additional constraints, microformats are semantic (X)HTML with additional constraints. In particular, the difference between the specific semantic XHTML technique that is using semantic class names, ids, rel/rev values and a microformat Is that *anyone* can make up semantic class names, id, rel/rev values, for any reason in any way, and in fact, modern web designers and information architects were doing so *long* before microformats was even coined as a term. Indeed, it was precisely this pre-existing behavior that inspired me to first even dare to propose microformats as a refinement thereof. A microformat is such because it is a use of semantic class names, etc. that IN PARTICULAR: 1. Are designed according to microformat principles [1] 2. Follow the microformats process [2] [1] http://microformats.org/wiki/microformats#the_microformats_principles [2] http://microformats.org/wiki/process Without those, all you have is semantic XHTML. I have on my to-do list to better document the principles, more thoroughly, etc., as well as update the process per what we have learned the past six months or so. Perhaps this holiday season I will have to spend some time catching up on this given the extent of this thread. http://microformats.org/wiki/to-do#introduction_.2F_community I will note that for now, much deeper explanations of the principles are actually presented in the numerous podcasts about microformats that have been published: http://microformats.org/wiki/podcasts I encourage everyone who has participated in this thread to listen to them. Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: the term microformat and encouraging people to play (was Re:[uf-discuss] Comments from IBM/Lotus rep about Microformats)
On 12/12/06 10:40 AM, S. Sriram [EMAIL PROTECTED] wrote: What ufs(.org) has done is bring about a new category i.e. microformats into the collective mindspace, similar to Palm computers. Without a brand name to go with the category microformats, What will happen, is the Darwinian like splintering of categories into sub categories as in iPod, Zune, BlackBerry etc. The term nor site microformats(.org) did not bring about a new category. The category pre-existed: semantic (X)HTML. microformats is the specific brand (your term) of semantic (X)HTML that follows the microformats principles and process. You could say that RDFa is another brand of semantic (X)HTML that follows its own principles. Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: microformats vs. semantic XHTML (was Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats)
Am Dienstag, 12. Dezember 2006 17:17 schrieb Tantek Çelik: lowercase microformats = unofficial semantic markup embedded in HTML uppercase microformats = Official Microformat There is no such thing as lowercase microformats. I think that came from the socalled lowercase semantic web vs. the uppercase semantic web. The first is the grassroots movement we all know as microformats, which is not highly official and, most of all, does take a small step approach to semantic web, i.e. not defining a new file format, just adding to an existing format. The socalled uppercase semantic web on the other hand is the rdf and owl effort of the w3c, which offers much more, but is hell complicated and defines two completely new file formats. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: the term microformat and encouraging people to play (wasRe:[uf-discuss] Comments from IBM/Lotus rep about Microformats)
From: Tantek Ç elik [EMAIL PROTECTED] The term nor site microformats(.org) did not bring about a new category. The category pre-existed: semantic (X)HTML. microformats is the specific brand (your term) of semantic (X)HTML that follows the microformats principles and process. You could say that RDFa is another brand of semantic (X)HTML that follows its own principles. Unfortunately, the use of a 'generic' term such as microformats turns it into a 'category', because categories are created by (all the others out there) others and inspired by products. Rather than us extending this debate, I might suggest that you file this away as the reason for the confusion. Solutions are entirely upto you and if you need further reading, besides al ries I might suggest you could also see seth godin's comments on podcasting rss http://sethgodin.typepad.com/seths_blog/2006/06/being_brave_wit.html S. Sriram ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: microformats vs. semantic XHTML (was Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats)
In message [EMAIL PROTECTED], Tantek Çelik [EMAIL PROTECTED] writes A microformat is such because it is a use of semantic class names, etc. that IN PARTICULAR: 1. Are designed according to microformat principles [1] 2. Follow the microformats process [2] Of all the definitions of microformats in circulation, including that on the main uFs web page, I believe that I have yet to see one which makes those stipulations. Without those, all you have is semantic XHTML. That's one opinion. Another, for example, would be that any set of classes (and rels, or whatever), used by a number of people, with various parsers and aggregators, and marked up examples in the wild, constitute a de facto microformat. The fact that the only such examples at present came about through the current 'wiki'/ mailing list/ 'community' does not preclude it from happening, elsewhere, in the future. I have on my to-do list to better document the principles, more thoroughly, etc., as well as update the process per what we have learned the past six months or so. When you do, will the proposed changes be posted here or on the wiki, for discussion by the 'community', or will they be, in effect, imposed? I will note that for now, much deeper explanations of the principles are actually presented in the numerous podcasts about microformats that have been published: http://microformats.org/wiki/podcasts I encourage everyone who has participated in this thread to listen to them. Where are their text transcriptions? -- Andy Mabbett * Say NO! to compulsory ID Cards: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Upper and lower case microformats (was: [uf-discuss] Comments from IBM/Lotus rep about Microformats)
In message [EMAIL PROTECTED], Mike Schinkel [EMAIL PROTECTED] writes lowercase microformats = unofficial semantic markup embedded in HTML uppercase microformats = Official Microformat Does: HTML is good. Microformats are wonderful refer to the former, or the latter? -- Andy Mabbett * Say NO! to compulsory ID Cards: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
On Dec 12, 2006, at 1:38 PM, Joe Andrieu wrote: brian suda wrote It is possible for me to start creating a CSS style called 'vcard', but a parser would know that this is a style and not semantics because of the lack of a profile URI. Eventually, as microformats become more popular, the profile URI is used to disambiguate random styles with intended semantic values. Brian, As I understand it profile URIs are not required. If so, the parser cannot distinguish between wild semantic HTML and an hCard. Profile URIs are not required for publishers, but parsers are free to ignore HTML without profile URIs, and I think it's reasonable to expect them to start doing that if name conflict becomes more than a hypothetical problem. This mirrors how natural language works. Until there is some need for clarification, we assume everyone knows what we mean. Then there is a need for clarification, we clarify. No one goes around defining every word before they use it, and I don't think we can expect publishers to behave differently with HTML symbols. We could require profile URIs, but that won't make anyone use them. OI think only a practical need for disambiguation will do that. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats
Benjamin West wrote: I'm not quite sure what you mean here. Is there a difference between lowercase microformats and uppercase microformats? lowercase microformats = unofficial semantic markup embedded in HTML uppercase microformats = Official Microformat -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats
Bruce D'Arcus wrote: In a world in which one CAN consider adding alternative attributes (HTML 5, etc.), it makes no sense to me one would simply say no. [I'm cross posting to uf-discuss and whatwg because Bruce's comment was made on uf-discuss but I've made the same point on WHATWG.] Bruce, I agree with you completely. But Ian Hickson has said that AFAHK that there was no cry for additional attributes on the uf-discuss list, And Ian also said he saw no need for them after I requested to get several attributes added to the list of attributes applicable to all elements, i.e. abbr, href, name, rel, rev, scope, size, src, type, and value. I hadn't had the chance to ask the uf-discuss list about this, so now is a perfect time. What about adding additional standard attributes to all elements. Would it be helpful? -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
On 12/11/06, Mike Schinkel [EMAIL PROTECTED] wrote: Benjamin West wrote: I'm not quite sure what you mean here. Is there a difference between lowercase microformats and uppercase microformats? lowercase microformats = unofficial semantic markup embedded in HTML uppercase microformats = Official Microformat That's the first I've heard of this usage. I think what I'm hearing (and agree with) is a need for a term that describes the product of semantic markup techniques in a general way. Lots of people are already doing this, and don't need any official body to bless them. Microformats (any casing) would be a subset of these products that are blessed by pervasive use across the web. I'm hesitant to pick out such a name, lest I choose badly (eg AJAX). I'm happy to let the market pick that name (eg I don't think anyone should deliberately pick it out.), but at the same time, I'm hesitant to let the term microformats be applied to general applications of general techniques. Does that reverberate at all with you, Mike, or anyone else? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
On Dec 11, 2006, at 11:43 PM, [EMAIL PROTECTED] wrote: Brian Suda wrote: Microformats are meant as building blocks and they should be able to be using independantly and together... If that is true, how can it be achieved without a disambiguation conventions to keep official Microformats from conflicting with similar techniques. Or is it the view of the Microformat community that Microformats will keep it's house clean and, because Microformats are the anointed ones that it just sucks to be the other guy? Since Microformats (capital-M) are based on research of current practice, I think it's probably more helpful to think of techniques as proto- Microformats. If the community is slow to develop a format that makes sense, we often encourage authors to develop their own systems, which then can inform how a format will function in the wild. This is where documentation and the oft-belabored process becomes powerful. Although it can be annoying for early-adopters and people who need solutions now, it creates strong formats once the issues are solidified. -- Ryan Cannon Interactive Developer MSI Student, School of Information University of Michigan http://RyanCannon.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats
Benjamin West wrote: That's the first I've heard of this usage. I think what I'm hearing (and agree with) is a need for a term that describes the product of semantic markup techniques in a general way. It's my usage. It seemed natural as I've heard the term uppercase/lowercase used to distinguish between official and unofficial in other areas in the past. Lots of people are already doing this, and don't need any official body to bless them. Agreed. I just see the need to give those people a way to disambiguate between themselves and Microformats. I've said the same here as well as on WHATWG. But I'm not gaining any success to date. People are saying it is a hypothetical problem while ignoring that I am saying it is an actual problem in my usage. Microformats (any casing) would be a subset of these products that are blessed by pervasive use across the web. I'm hesitant to pick out such a name, lest I choose badly (eg AJAX). I'm happy to let the market pick that name (eg I don't think anyone should deliberately pick it out.), but at the same time, I'm hesitant to let the term microformats be applied to general applications of general techniques. Does that reverberate at all with you, Mike, or anyone else? That's exactly what I see going on here and discuss on WHATWG, so yes. Ian Hickson called it Keywords in the HTML extension mechanism and I reverted to calling it semantic markup embedded in HTML. Maybe we could call it SemMarE? (yeah, I suck a making up names too. ;-) -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats
Also sprach Mike Schinkel: I'm not quite sure what you mean here. Is there a difference between lowercase microformats and uppercase microformats? lowercase microformats = unofficial semantic markup embedded in HTML uppercase microformats = Official Microformat This makes sense to me. Preventing people from using the term microformat for their own set of class names is an uphill battle; the term microformat is simply too attractive. Besides, people should be encouraged to play. Most private sets will quickly die a natural death and do no harm. Those who survive in the wild deserve the capital M. -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
Forgive me if I have missed something, but could a parser not understand multiple formats if the HTML used was also meaningful? For example a blocklevel element (say a p) could contain some content that was marked up with one microformat, and another blocklevel element could contain content marked up with another entirely different microformat. The fact that they shared the same page isn't a problem. A parser could easily identify child relationships within the HTML and extrapolate. Granted this wouldn't be so easy if two microformats were muddled together on the same page. And if they were then maybe there are two questions to ask. 1/ Is the microformat in need of some additional elements?, and 2/ Is the author of the page trying to do too much. could it be laid out differently? Simple is better afterall. Tim On 09/12/06, Mike Schinkel [EMAIL PROTECTED] wrote: Ryan King wrote: How can I disambiguate when two Microformats collide? Let me give a concrete example (one I will be working on in the future): First profile wins. This had previously been clarified in HTML5, until Hixie decided to remove the profile attribute from HTML5. Please tell me if I misunderstand, but I think that clearly identifies the problem I've been trying to address: naming clashes on a scare resource. If what I think you said is correct, that would require someone to use one or the other, but not both. That approach to web architecture is clearly not acceptable, don't you agree? -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- Tim Hodson informationtakesover.co.uk www.timhodson.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
In message [EMAIL PROTECTED], Tim Hodson [EMAIL PROTECTED] writes A parser could easily identify child relationships within the HTML and extrapolate. Granted this wouldn't be so easy if two microformats were muddled together on the same page. AIUI the concerns are about using the same class-name for two different attributes. Say, the title of a book in a citation, vs. a job title in an hCard. Since a citation may include the author's hCard, it is thought that there might be a conflict: div class=citation span class=title Running an ISP for Idiots /span div class=author div class=vcard span class=title Internet Expert [1] /span div div div There is a danger that Internet Expert might be recorded as the title of the book (especially if the other title attribute is not present) Several possible solutions are available to us: 1Declare that, if the attribute is inside a microformat (in this case hCard), then it always applies to that uF, but not the parent uF (in this case the citation) 2Uniquely name the first attribute as, say, class=book-title (compare to some of the proposed class names in the 'species' proposal, which use this method to avoid other clashes). 3Use an additional wrapper around the hCard on an additional class on the hCard), to indicate that anything within that wrapper does not apply to the parent. My preference is for option 2 - with hindsight, I would have named all the classes in hCard as, say, vcard-title. [1] I actually knew of someone who has this as their job title ;-) -- Andy Mabbett * Say NO! to compulsory ID Cards: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
On 09/12/06, Andy Mabbett [EMAIL PROTECTED] wrote: div class=citation span class=title Running an ISP for Idiots /span div class=author div class=vcard span class=title Internet Expert [1] /span div div div There is a danger that Internet Expert might be recorded as the title of the book (especially if the other title attribute is not present) Several possible solutions are available to us: 1Declare that, if the attribute is inside a microformat (in this case hCard), then it always applies to that uF, but not the parent uF (in this case the citation) Surely 1 is the most logical? The fact that the hcard title is NOT in the parent citation block would surely mean that I could make the sensible assumption that the title attribute for the hcard is NOT the same as the title attribute of the citation. It would be up to me as author to clearly express what I meant by using correctly nesting tags. 2Uniquely name the first attribute as, say, class=book-title (compare to some of the proposed class names in the 'species' proposal, which use this method to avoid other clashes). The citation may not be a book :) 3Use an additional wrapper around the hCard on an additional class on the hCard), to indicate that anything within that wrapper does not apply to the parent. As for 3, this is already done in the example given. The wrappers are named hcard and citation, which brings us back to option 1. My preference is for option 2 - with hindsight, I would have named all the classes in hCard as, say, vcard-title. Naming all the classes with a prefix is unnecessary if you take the view that a microformat is a small set of attributes for distinct pieces of information. As far as I know (and I haven't read every microformat spec) there is almost always a root attribute which defines what we are talking about - vcard, vevent, xoxo, the exceptions are the rel/rev attributes which are defined using profiles and can only sensibly have one meaning in a page. best... -- Tim Hodson informationtakesover.co.uk www.timhodson.co.uk selfdescription.org ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
In message [EMAIL PROTECTED], David Janes [EMAIL PROTECTED] writes My recent thinking has been that the following rules may work: An outer microformat should - never look for attributes inside nested microformats (particularly hCard, hCalendar, hAtom and xFolk) You immediately hit problems with adr and geo inside hCard. - never look for attributes inside BLOCKQUOTE or Q Why not? - unless explicitly defined to be otherwise How would that be done? -- Andy Mabbett * Say NO! to compulsory ID Cards: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
On 12/9/06, David Janes [EMAIL PROTECTED] wrote: My recent thinking has been that the following rules may work: An outer microformat should - never look for attributes inside nested microformats (particularly hCard, hCalendar, hAtom and xFolk) --- i would also disagree with this because then you creating dependancies across ALL microformats, now and forever. If i create a VALID hCard 1.0 parser... in 2 years when hFooBar hits the web, my VALID 1.0 parser is no longer valid - other microformats could obsolete existing standards. Microformats are meant as building blocks and they should be able to be using independantly and together... otherwise everytime someone marked-up an hCalendar with an hCard for the venue, your hCalendar location would be empty. It's not a bug, it's a feature. -- brian suda http://suda.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
On 12/9/06, Brian Suda [EMAIL PROTECTED] wrote: On 12/9/06, David Janes [EMAIL PROTECTED] wrote: My recent thinking has been that the following rules may work: An outer microformat should - never look for attributes inside nested microformats (particularly hCard, hCalendar, hAtom and xFolk) --- i would also disagree with this because then you creating dependancies across ALL microformats, now and forever. If i create a VALID hCard 1.0 parser... in 2 years when hFooBar hits the web, my VALID 1.0 parser is no longer valid - other microformats could obsolete existing standards. Microformats are meant as building blocks and they should be able to be using independantly and together... otherwise everytime someone marked-up an hCalendar with an hCard for the venue, your hCalendar location would be empty. It's not a bug, it's a feature. How would someone marking up a hCalendar with a hCard make the location empty under those rules? The hCard is part of the hCalendar, both as part of the spec [1] and implicitly because it's there. Ignoring the fact that it's part of the spec, my point still holds: the _attributes_ of the hCard associate with the hCard and the hCard as a _whole_ then is associated with the hCalendar. Now, to understand your hFooBar example, consider two possibities: hFooBar is embedded inside of (say) hCalendar, or hCalendar is used inside of hFooBar. If hFooBar is written to reuse class names from hCalendar, your 1.0 parser is going to be confused (interpret the microformat incorrectly) in the embedded case _no matter what_. In the enclosing case (i.e. hFooBar encloses hCalendar), it makes no difference because your 1.0 parser does not see hFooBar. If hFooBar does not reuse class names, the your 1.0 parser is fine in both cases. Regards, etc... [1] http://microformats.org/wiki/hcalendar#More_Semantic_Equivalents ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Re: Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
On 12/9/06, David Janes [EMAIL PROTECTED] wrote: How would someone marking up a hCalendar with a hCard make the location empty under those rules? The hCard is part of the hCalendar, both as part of the spec [1] and implicitly because it's there. You wrote earlier: An outer microformat should - never look for attributes inside nested microformats (particularly hCard, hCalendar, hAtom and xFolk) --- sorry, i took your: NEVER to mean NEVER-EVER and not NEVER, except when it is part of the spec. i still think/feel that excluding embeded microformats inside other microformats is a bad idea. The whole point of NOT having namespaces is that the property values that we put into class/rel/rev have the same consistent meaning across all formats and therefore SHOULD be considered even when nested because it IS the same meaning. As it stands, hCard does NOT have any rules for other microformats to be nested inside of it... So if i were to do something like: div class=vcard span class=fnBrian Suda/span div class=vevent div class=summaryMy Birthday/div abbr class=dtstart bday title=1800-01-01Jan 1st/abbr /div div class=hFooBar img src=images/me.png class=photo / /div /div According to the Never look inside other microformats when parsing the outermost format the bday value would never be picked-up by the hCard parser. Also, if/when hFoobar came-out, if to be a valid parser you can't parse inside other formats it would HAVE to know NOT to parse inside hFooBar and how would it know not to do that unless, when each new format is minted, all previous formats must also update? that doesn't make sense to do. I think that the other nested formats should be transparent and any parser can look inside any other format - that's why we choose property values that apply across the whole microformats spectrum. Does that make sense? or are we both arguing (and agreeing) about the same thing and just not realising it? -brian -- brian suda http://suda.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
- never look for attributes inside BLOCKQUOTE or Q Why not? Because their definitions in the HTML spec [1] say that these are for pulling in data from elsewhere. From this one concludes that it's likely that this data is not necessarily going to be marked up in a way consistent with the current page. - unless explicitly defined to be otherwise How would that be done? When writing a new microformat, one says we look inside X Y and Z for A B and C Regards, etc... [1] http://www.w3.org/TR/REC-html40/struct/text.html#edef-BLOCKQUOTE ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Re: Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
On 12/9/06, Brian Suda [EMAIL PROTECTED] wrote: i still think/feel that excluding embeded microformats inside other microformats is a bad idea. The whole point of NOT having namespaces is that the property values that we put into class/rel/rev have the same consistent meaning across all formats and therefore SHOULD be considered even when nested because it IS the same meaning. As it stands, hCard does NOT have any rules for other microformats to be nested inside of it... So if i were to do something like: div class=vcard span class=fnBrian Suda/span div class=vevent div class=summaryMy Birthday/div abbr class=dtstart bday title=1800-01-01Jan 1st/abbr /div div class=hFooBar img src=images/me.png class=photo / /div /div According to the Never look inside other microformats when parsing the outermost format the bday value would never be picked-up by the hCard parser. Also, if/when hFoobar came-out, if to be a valid parser you can't parse inside other formats it would HAVE to know NOT to parse inside hFooBar and how would it know not to do that unless, when each new format is minted, all previous formats must also update? that doesn't make sense to do. I think that the other nested formats should be transparent and any parser can look inside any other format - that's why we choose property values that apply across the whole microformats spectrum. Does that make sense? or are we both arguing (and agreeing) about the same thing and just not realising it? We're not talking about the same thing but I think the case you're making here is pretty strong. The issue that I've been trying to solve in my mind (and I'm sure we're all on the same page here) is given an attribute A nested in micrformats M, N and P (from inner to outer), is what does A belong to. If the answer is all of them then there seems to seems to be a potential conflict consistent meaning and same meaning. Consider this nesting: body div class=hentry ... div class=published8 December 2006/div /div div class=published9 December 2006/div /body In this example, I'm reusing published to mean to the date of publication of a microformatted object; in one case, a blog entry and in the other case, the page itself. This reuses the published class from hAtom to a new microformat for describing the publication date of the page (some research has happened on this in the past). If we ask the parser for give me the publication date of the page, then obviously it has the sort out which to use. We could define a whole new class for describing the publication date of the page, but then we have multiple classes meaning more or less the same thing. I don't have a happy solution for this and maybe it just comes down to work it out case by case. However, I potentially see it to be very useful to reuse things like fn in nested microformats. I'm still happy with the BLOCKQUOTE/Q rules. Regards, etc... David ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Re: Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
On 12/9/06, David Janes [EMAIL PROTECTED] wrote: On 12/9/06, Brian Suda [EMAIL PROTECTED] wrote: [snip] We're not talking about the same thing but I think the case you're making here is pretty strong. The issue that I've been trying to solve in my mind (and I'm sure we're all on the same page here) is given an attribute A nested in micrformats M, N and P (from inner to outer), is what does A belong to. If the answer is all of them then there seems to seems to be a potential conflict consistent meaning and same meaning. I'm trying to stay out of this because of I'm being consumed by other commitments, but I'm really pleased to see a very healthy ongoing conversation on the subject on this list. I think I really like the way that David is stating the issue and am patiently hoping to see the uf community taking this issue up further and watching for an outcome. As an aside, I'm going to refocus my semantic html efforts from worrying too much about the new attributes (e.g. RDFa: about, property, etc) and worrying about mechanisms to resolve cases such as the one posted by David. However, more importantly, I need to find an important enough instance of the so-called problem that needs us to resolve the general microformat(s) case instead of hoping that if we build it, they will come. -Elias ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Re: Re: Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
Thanks Elias for weighing in, i was getting abit worried that people might have been putting words in your mouth, it is glad to know you are on the list to clear-up any potential confusions. -brian On 12/9/06, Elias Torres [EMAIL PROTECTED] wrote: On 12/9/06, David Janes [EMAIL PROTECTED] wrote: On 12/9/06, Brian Suda [EMAIL PROTECTED] wrote: [snip] We're not talking about the same thing but I think the case you're making here is pretty strong. The issue that I've been trying to solve in my mind (and I'm sure we're all on the same page here) is given an attribute A nested in micrformats M, N and P (from inner to outer), is what does A belong to. If the answer is all of them then there seems to seems to be a potential conflict consistent meaning and same meaning. I'm trying to stay out of this because of I'm being consumed by other commitments, but I'm really pleased to see a very healthy ongoing conversation on the subject on this list. I think I really like the way that David is stating the issue and am patiently hoping to see the uf community taking this issue up further and watching for an outcome. As an aside, I'm going to refocus my semantic html efforts from worrying too much about the new attributes (e.g. RDFa: about, property, etc) and worrying about mechanisms to resolve cases such as the one posted by David. However, more importantly, I need to find an important enough instance of the so-called problem that needs us to resolve the general microformat(s) case instead of hoping that if we build it, they will come. -Elias ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- brian suda http://suda.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
On Dec 9, 2006, at 10:45 AM, Elias Torres wrote: However, more importantly, I need to find an important enough instance of the so-called problem that needs us to resolve the general microformat(s) case instead of hoping that if we build it, they will come. Exactly. That's my primary concern with trying to solve this problem right now: building a solution around hypothetical publishing makes the solution more likely to fail when real publishing shows up. I think it would be good if more publishers were adding their own non- microformat semantics to their HTML to see how multiple experiments actually conflict and how those conflicts are most easily resolved before we formalize the process. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[admin] Declaring end of thread (was Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats)
In message [EMAIL PROTECTED], Tantek Çelik [EMAIL PROTECTED] writes I am ending this thread of 50 messages now That's interesting - with what authority do you declare end of thread. Isn't this supposed to be a community, and isn't that or the community to do? If there is an autocracy (or some other non-community based management system) here, then surely it should be openly and honestly documented? Parsing is OFF-TOPIC for microformats-discuss. Such discussions belong in microformats-dev. See the mailing-lists page on the wiki where this has been documented for quite some time: [...] And then - if you are not actually working on (i.e. coding) a parser, then please don't post until you are. So, parsing should only be discussed by people who are actively writing parsers? And someone proposing a microformat should not comment on how it is intended to be parsed? And someone using uFs in their mark-up, perhaps for the first time, should not ask questions about, nor comment on, how they are being parsed? If so, that would have made this conversation: http://microformats.org/discuss/mail/microformats-discuss/2006-September/005957.html illegal, resulting in the loss of the benefits gained form it. It would also prohibit the discussion of most use-cases, and would prohibit a proponent from answering questions about their proposed microformat. Also prohibited would be the reporting of bugs in parsers: http://microformats.org/discuss/mail/microformats-discuss/2006-September/005438.html Theoretical worries are not a priority. They may not be *your* priority, but few inventions or advancements could have been made, without some consideration of theoretical matters. 2. Use real world examples for discussions. Throughout this thread there have been numerous arguments based on strictly theoretical examples. The problem is we can waste ALL our time from now until forever discussing/worrying about theoretical examples and get nothing done. Your implication, that all theoretical examples result in time wasting, is unfounded. Theoretical examples are the equivalent to a DOS attack on actually getting things done. Such hyperbole! 3. Prefixing (e.g. vcard-) has already been considered and rejected for microformats in general. There have been deliberate exceptions made for one microformat (hAtom). I'm not going to spend the time re-arguing this now - I have added an item to my to-do list on the wiki to better document this. Thank you for making clear that it's currently not (well) documented. Are we to understand also, that every decision, once made, even if ill-documented, is irrevocable? Or should we deduce that, if deliberate exceptions can be made in one case, it is perfectly reasonable to suggest that deliberate exceptions be made in another? Put another way: how are we to resolve the clear inconsistency in your third point? -- Andy Mabbett * Say NO! to compulsory ID Cards: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
admins, prefix exceptions (was Re: [admin] Declaring end of thread (was Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats))
On 12/9/06 12:11 PM, Andy Mabbett [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Tantek Çelik [EMAIL PROTECTED] writes I am ending this thread of 50 messages now That's interesting - with what authority do you declare end of thread. Isn't this supposed to be a community, and isn't that or the community to do? If there is an autocracy (or some other non-community based management system) here, then surely it should be openly and honestly documented? I am an admin on this list/site as is Ryan King. parsing discussion snipped because it is off topic for this list theoretical worries also snipped because they are not a priority for microformats 3. Prefixing (e.g. vcard-) has already been considered and rejected for microformats in general. There have been deliberate exceptions made for one microformat (hAtom). I'm not going to spend the time re-arguing this now - I have added an item to my to-do list on the wiki to better document this. Thank you for making clear that it's currently not (well) documented. Are we to understand also, that every decision, once made, even if ill-documented, is irrevocable? No. Or should we deduce that, if deliberate exceptions can be made in one case, it is perfectly reasonable to suggest that deliberate exceptions be made in another? Yes exceptions can be made but only with exceptionally good reasons. In the case of hAtom, you can read through the archives for the reasoning in depth, but in summary: since we were reusing the semantics of the IETF Atom standard, we very much wanted to reuse the vocabulary as well to minimize confusion and mean precisely the same semantics as defined in the Atom RFC 4287, and thus a few of the hAtom properties appear to be prefixed (entry-title, entry-content, entry-summary) in order to literally reuse those terms from the RFC (title, content, summary). Perhaps that would be a good hatom-faq entry. Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
admins, prefix exceptions (was Re: [admin] Declaring end of thread (was Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats))
In message [EMAIL PROTECTED], Tantek Çelik [EMAIL PROTECTED] writes I am ending this thread of 50 messages now That's interesting - with what authority do you declare end of thread. Isn't this supposed to be a community, and isn't that or the community to do? If there is an autocracy (or some other non-community based management system) here, then surely it should be openly and honestly documented? I am an admin on this list/site as is Ryan King. I know. That doesn't address my point. parsing discussion snipped because it is off topic for this list Your refusal to address my concerns and answer questions on the administration of *this list*, and its use by the community, is duly noted. theoretical worries also snipped because they are not a priority for microformats microformats is not a sentient entity, it cannot have a view on such matters. 3. Prefixing (e.g. vcard-) has already been considered and rejected for microformats in general. There have been deliberate exceptions made for one microformat (hAtom). I'm not going to spend the time re-arguing this now - I have added an item to my to-do list on the wiki to better document this. Thank you for making clear that it's currently not (well) documented. Are we to understand also, that every decision, once made, even if ill-documented, is irrevocable? No. Or should we deduce that, if deliberate exceptions can be made in one case, it is perfectly reasonable to suggest that deliberate exceptions be made in another? Yes exceptions can be made but only with exceptionally good reasons. So it's perfectly acceptable to make such a suggestion. Good. -- Andy Mabbett * Say NO! to compulsory ID Cards: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
false claim regarding relevance of topics on this list (was: [admin] Declaring end of thread (was Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats))
In message [EMAIL PROTECTED], Tantek Çelik [EMAIL PROTECTED] writes 1. Parsing is OFF-TOPIC for microformats-discuss. Furthermore, your assertion is not supported by: http://microformats.org/wiki/mailing-lists A mailing list for general discussion of microformats nor: http://microformats.org/discuss/ This is a public list for discussion of microformats. Unmoderated, open subscription. nor: http://microformats.org/mailman/listinfo/microformats-discuss/ This is an open and public list for anyone interested in microformats. -- Andy Mabbett * Say NO! to compulsory ID Cards: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
On 12/7/06, Ryan King [EMAIL PROTECTED] wrote: ... Also, I'm not sure how 'people not getting their pet properties' is a problem specific to microformats. True. It doesn't mean it has to repeat the same mistake though. I would certainly hope the HTML 5 effort would be open minded about learning from all of the efforts in this space. HTML 5 has profile URIs and the specification is much more clear as to how they are to be used (thanks to Tantek bugging Hixie about that). I think HTML 5's current extension methods (profiles, rel and class) are sufficient. Let's review: Microformts are a clever set of conventions to reuse existing HTML attributes to encode some sort of structured meaning. However, using title to encode machine-readable content is pretty much a hack. Title, after all, is really for human readable labels. Likewise, using class to indicate both properties and, um, class, is also a hack. These hacks are no doubt necessary and practical in the context of current HTML and I really have no problem with it in that context, but it's precseily why there can be no generic microformat parser. In a world in which one CAN consider adding alternative attributes (HTML 5, etc.), it makes no sense to me one would simply say no. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
On Dec 8, 2006, at 4:04 AM, Bruce D'Arcus wrote: Let's review: Microformts are a clever set of conventions to reuse existing HTML attributes to encode some sort of structured meaning. However, using title to encode machine-readable content is pretty much a hack. Title, after all, is really for human readable labels. I agree, it's not the cleanest of possible solutions. It *is* a compromise. Find us something better and we'll switch. Likewise, using class to indicate both properties and, um, class, is also a hack. I'm not sure how you can justify claiming this. You must have read a different HTML specification than I have, because in my reading, there are no limits on how the class attribute can be used in HTML. According to the spec, it's available for general processing by user agents. I've explained more fully before [http:// microformats.org/blog/2005/10/19/more-than-styling/]. These hacks are no doubt necessary and practical in the context of current HTML and I really have no problem with it in that context, but it's precseily why there can be no generic microformat parser. You say that like it's a bad thing. Show me a generic parser that works on the scale of The Web. Even HTML parsers are not generic– browser vendors commonly have to vary their browser's behavior from site to site in order to deal with differences. At least the same microformat can be extracted from different sites in the same way (once you know how to parse the HTML :D). -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: class=hack? Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
On 12/8/06, Dr. Ernie Prabhakar [EMAIL PROTECTED] wrote: On Dec 8, 2006, at 4:04 AM, Bruce D'Arcus wrote: Likewise, using class to indicate both properties and, um, class, is also a hack. I think that's probably where we part company. I suspect most of us here consider the use of HTML class for semantic information fully in line with the both the letter and spirit of the spec, and thus an entirely natural usage. My point, Ernie, is there's no obvious way to map it onto a model. I don't think that's such a controversial thing to say. We've got tables and columns (RDBMSes), resources and properties (RDF), objects and attributes (oo). Class and ... ? Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: class=hack? Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
Hi Bruce, My point, Ernie, is there's no obvious way to map it onto a model. I Um, maybe I'm not quite understanding what you mean by model. Are you saying that there's no way to create a generic parser that transforms the microformatted data into a normalized form? What you may not realize (I didn't at first either) is that microformats.org is -- by *definition* -- optimizing for a world there are only a handful of discrete microformats. Thus, there is no point in worrying about the general case; there are only special cases, and a relatively small number of those. You may not believe or agree with that definition (not all of us do either :-), but that's the rules we play by here. If you want a more generic approach, you might be happier with GRDDL. Cheers, -- Ernie P. On Dec 8, 2006, at 2:11 PM, Bruce D'Arcus wrote: On 12/8/06, Dr. Ernie Prabhakar [EMAIL PROTECTED] wrote: On Dec 8, 2006, at 4:04 AM, Bruce D'Arcus wrote: Likewise, using class to indicate both properties and, um, class, is also a hack. I think that's probably where we part company. I suspect most of us here consider the use of HTML class for semantic information fully in line with the both the letter and spirit of the spec, and thus an entirely natural usage. My point, Ernie, is there's no obvious way to map it onto a model. I don't think that's such a controversial thing to say. We've got tables and columns (RDBMSes), resources and properties (RDF), objects and attributes (oo). Class and ... ? Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats
Ryan King wrote: How can I disambiguate when two Microformats collide? Let me give a concrete example (one I will be working on in the future): First profile wins. This had previously been clarified in HTML5, until Hixie decided to remove the profile attribute from HTML5. Please tell me if I misunderstand, but I think that clearly identifies the problem I've been trying to address: naming clashes on a scare resource. If what I think you said is correct, that would require someone to use one or the other, but not both. That approach to web architecture is clearly not acceptable, don't you agree? -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats
Mike Schinkel wrote: 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.) Mike, you've raised some excellent concerns. It fundamentally boils down to an issue of interoperability. If the Microformat's community splinters and, say, multiple versions of hCard are created then we immediately have an interoperability problem. Tantek calls namespaces an enabler of stovepipes. I hope that Tantek will weigh in on this issue. In the past he has addressed this issue, but a regular repeat is very worthwhile I believe. It strikes at the very heart of the Microformat's philosophy, and the very heart of achieving interoperability on the Web. /Roger ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
On Dec 6, 2006, at 5:45 AM, Bruce D'Arcus wrote: On 12/5/06, Scott Reynen [EMAIL PROTECTED] wrote: ... In HTML or JSON, new formats need new parsers, which must be written by someone. Exactly. The point is if you have a generic model you have a generic parser. Elias is coming from an RDF background, and microformats simply aren't RDF, and they never will be. And that's a good thing. If what you want is RDF, just use RDF. The issue isn't really microformats vs. RDF (except as RDF provides a model), but microformats vs. RDFa. Both microformats and RDFa are addressing the exact same use cases and requirements (augmenting visible content with structured data). 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. Yes, in order to parse and consume microformats, you'll have to have code that knows about those formats. The RDF dream of having a generic parser and model has yet to win on the open web. I'm more than happy to let the market decide whether it's more value to have formats that are easy to publish, or those that are easy to parse (I'm sure you can guess which side I'll take). 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 that there are cases where we can be more organized and I'm more than willing to implement new tools or processes to do this. Also, I'm not sure how 'people not getting their pet properties' is a problem specific to microformats. With other technologies, like XML, the person who didn't get their pet property included in a given namespace could create their own namespace and advocate that people make use of it. Still, I don't believe that it changes the reality that tools won't know what to do with it unless *someone* writes some code. I don't think the situation is any worse in microformats, and it may in fact be better. If your 'pet property' doesn't make it into a microformat, you can still publish it and advocate that others use it. If consumers of said microformat decide that the data is valuable, they'll parse it and if enough people do this, then it'll get added to the microformat. -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats
S. Sriram wrote: This is not a scarce resource, people can (and are) naming classes as they choose. Any constraint happens at the parsing stage, since microformat-aware parsers look for specific class names etc. (see below) If it is not a scarce resource, please tell me what would happen if I decided to start marking up documents, as an example, using the class directory and license, for purposes other than rel-directory and re-license? How could my markup and those Microformats co-exist in the same HTML document? -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
On 12/7/06, Ryan King [EMAIL PROTECTED] wrote: ... The RDF dream of having a generic parser and model has yet to win on the open web. I'm more than happy to let the market decide whether it's more value to have formats that are easy to publish, or those that are easy to parse (I'm sure you can guess which side I'll take). Why does this need to be an either/or choice? Why must ease-of-authoring trade-off generality here? ... Also, I'm not sure how 'people not getting their pet properties' is a problem specific to microformats. True. It doesn't mean it has to repeat the same mistake though. I would certainly hope the HTML 5 effort would be open minded about learning from all of the efforts in this space. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
On Dec 7, 2006, at 12:29 PM, Bruce D'Arcus wrote: On 12/7/06, Ryan King [EMAIL PROTECTED] wrote: ... The RDF dream of having a generic parser and model has yet to win on the open web. I'm more than happy to let the market decide whether it's more value to have formats that are easy to publish, or those that are easy to parse (I'm sure you can guess which side I'll take). Why does this need to be an either/or choice? Why must ease-of-authoring trade-off generality here? I'm not saying that it has to be, but that it appears to be so in practice. I've found that general purpose data formats are harder to author than specific ones. For example, HTML is more work than Markdown for the kinds of writing that Markdown allows. I tend to use Markdown pretty often because of that. ... Also, I'm not sure how 'people not getting their pet properties' is a problem specific to microformats. True. It doesn't mean it has to repeat the same mistake though. I would certainly hope the HTML 5 effort would be open minded about learning from all of the efforts in this space. HTML 5 has profile URIs and the specification is much more clear as to how they are to be used (thanks to Tantek bugging Hixie about that). I think HTML 5's current extension methods (profiles, rel and class) are sufficient. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
From: Ryan King [EMAIL PROTECTED] On Dec 5, 2006, at 8:48 AM, S. Sriram wrote: From: Mike Schinkel [EMAIL PROTECTED] http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006- December/00 8462.html I wonder if his issues can be addressed? How about a distributed parser-discovery service What's wrong with GRDDL [http://www.w3.org/2004/01/rdxh/spec]? Nothing. Except that in this case it introduces yet another parsing burden on the browser/renderer i.e. from rdf/xml to JSON or other renderable format. S. Sriram ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
From: Mike Schinkel [EMAIL PROTECTED] S. Sriram wrote: This is not a scarce resource, people can (and are) naming classes as they choose. Any constraint happens at the parsing stage, since microformat-aware parsers look for specific class names etc. (see below) If it is not a scarce resource, please tell me what would happen if I decided to start marking up documents, as an example, using the class directory and license, for purposes other than rel-directory and re-license? How could my markup and those Microformats co-exist in the same HTML document? They would simply co-exist. Period. Hypothetically, say the author uses rel-license for some internal markup and has unwittingly cut/pasted in a uf-snippet containing a rel-license tag. The consumer of this microformat will now be presented with spurious/confusing data. How different is this from a web page (today) that contains a rel-license entry which was not intended to be a microformat in the first place. Not much. This too will lead to a spurious/confusing interpretation if consumed as a microformat. But, is that not what ALL current usages of this are and is that not how microformats even chooses these terms by sifting through the way people actually use them. In other words, just finding a markup on a page that resembles a microformat 'does not necessarily mean that is is one'. This is true today. The burden of interpretation is on the consumer not the author. Now, if the argument is that authors are 'constrained' in their class naming freedom, and have to avoid the usage of rel-license altogether (unless used as specifically noted by microformats.org) since microformats have 'squatted' on it. The response is NO, you are not constrained, as the burden of interpretation falls on the consumer of the microformat and not its author. As for multiple namespaces and a bureaucracy to govern that, it is highly unlikely. What is more likely is a white/blacklisting mechanism if spammers etc. begin wide use of it, much the same way blogs are being white/blacklisted. S. Sriram ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
On Dec 7, 2006, at 2:28 PM, Mike Schinkel wrote: If it is not a scarce resource, please tell me what would happen if I decided to start marking up documents, as an example, using the class directory and license, for purposes other than rel-directory and re-license? The classes wouldn't cause any problems, but if you mean the rel attribute, that would cause parsers to do confusing things with the data. Then people would start complaining to the parser developers, and the parser developers would start ignoring those attributes unless they were accompanied by the appropriate profile headers. And then publishers would start using the appropriate profile headers to disambiguate their microformats. None of that is happening now because there's no (or very little) ambiguity now, so there's little incentive to pre-emptively disambiguate. But if ambiguity ever becomes a real problem, there's a solution in profile headers ready to be used. The next question I expect is: what if you want to use both the microformats.org rel-license and your own conflicting rel-license in the same document? Well, you can't. Just like in natural language, if you want to start using symbols with meanings that conflict with the established standard, you need to be prepared to establish a new standard meaning. And the usefulness of your new meaning, rather than some central authority, will determine whether or not people use it in place of the alternative meaning. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats
--- these values are not reserved across all of HTML. We have a mechanism to prevent this, it is called Profile URIs, if a parser comes across class=vcard then the best way to determine if this is a random CSS Style or a semantic value is to see if there is a Profile URI that matched the XMDP of hCard. Are you referring to this? http://www.w3.org/TR/html401/struct/global.html#profiles Is a Profile URI a well-known URI where I have to find semantics elsewhere or if not what format is returned by the URI? (just trying to understand) How can I disambiguate when two Microformats collide? Let me give a concrete example (one I will be working on in the future): Looking at ADR, here is an example: div class=adr div class=street-address665 3rd St./div div class=extended-addressSuite 207/div span class=localitySan Francisco/span, span class=regionCA/span span class=postal-code94107/span div class=country-nameU.S.A./div /div Now let's say I want to use something called RegionData where Regions are heirarchical: div class=region-data div class=region street title=child-of-city 665 3rd St.; Suite 207 /div span class=region city title=child-of-stateSan Francisco/span, span class=region state title=child-of-countryCA/span span class=post-code94107/span div class=region country title=child-of-continentU.S.A./div /div Now, someone needs to use both: div class=region-data vcard div class=region street title=child-of-city div class=street-address665 3rd St./div div class=extended-addressSuite 207/div /div span class=region city locality title=child-of-stateSan Francisco/span, span class=region state region title=child-of-countryCA/span span class=post-code postal-code94107/span div class=region country country-name title=child-of-continentU.S.A./div /div How do I disambiguate between region-data's region and vcard's region? Assume I created my RegionData with no knowledge that vcard existed, because unless there is a central clearing house to avoid name clashes, two different groups will end up creating conflicting microformats with clashing names. It is also only a hypothetical issue, so until this becomes a real issue, we're not going to worry too much about it, but we do have a system that solves this problem. So we aren't squatting on any values. Hypothetical issues sometimes have a way of biting people in the ass, using a phrase Mark Baker recently said on the REST-discuss forum on another topic. :) However, this is not a hypothetical issue. A project I'm working on that I'm not willing to go public with yet will make heavy use of microformats-like markup, and I've already seen a lot of potential for collision such as the one above, which is an example of a planned use. But maybe Profile URIs can solve this. Can you please explain how, using my example? -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats
S. Sriram wrote: They would simply co-exist. Period My only response to your comments is that I strongly disagree with you, but as you appears you have a similar conviction it would be a waste of time to debate it further. -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
On 12/5/06, Scott Reynen [EMAIL PROTECTED] wrote: ... In HTML or JSON, new formats need new parsers, which must be written by someone. Exactly. The point is if you have a generic model you have a generic parser. Elias is coming from an RDF background, and microformats simply aren't RDF, and they never will be. And that's a good thing. If what you want is RDF, just use RDF. The issue isn't really microformats vs. RDF (except as RDF provides a model), but microformats vs. RDFa. Both microformats and RDFa are addressing the exact same use cases and requirements (augmenting visible content with structured data). 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. So while it might be comforting to dismiss RDFa and it's not our problem, I don't think it's good strategy. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
From: Bruce D'Arcus [EMAIL PROTECTED] The issue isn't really microformats vs. RDF (except as RDF provides a model), but microformats vs. RDFa. [snip] So while it might be comforting to dismiss RDFa and it's not our problem, I don't think it's good strategy. I agree.. Parsing Per [1] RDFa is akin to a language for microformats, as opposed to the current microformats which are a 'particular' defined set of class names in a defined order. A 'language parser' could parse all combinations of 'syntactically' correct RDFa, whereas with microformats each particular format requires a particular parser. Rendering Now when it comes to rendering the 'parsed output', knowing what the parsed output is, is necessary. This is where the need is to understand the 'particular output' *OR* have a generic container (an hItem or a micro-microformat for an item) so all-purpose renderers can view 'unknown/particular' parsed output as a blackbox. Distributed parsing Allows for custom microformats to be developed with their associated custom parsers and the output passed to the rendering engine. (possibly discovered by distributed rendering) Note: This does not need any 'approval process' as all publishers are free to do this today i.e. build a custom microformat, markup their pages appropriately, build a browser plug-in that understands this and build a cutom renderer. In other words, in the absence of a language parser (which can parse all combinations of a syntactically correct RDFa) the other way to accomodate custom microformats (elias's need) is through distributed parsing. Another way to look at it is that microformats (with defined formats == known rendering) are aggregator-friendly, where RDFa and distributed parsing/rendering are more user/institution friendly which may explain where google/technorati(aggregator) v. ibm(institution) are coming from. My own feeling is that a model which includes both 1. a uf-language (RDFa) and 2. canned formats (microformats) allows for greater flexibility, with canned formats allowing for aggregators/multiple tool vendors, where custom format developers would have the burden/opportunity of rolling their own renderers. [1] http://www.w3.org/TR/xhtml-rdfa-primer/ S. Sriram ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
On Dec 6, 2006, at 7:45 AM, Bruce D'Arcus wrote: On 12/5/06, Scott Reynen [EMAIL PROTECTED] wrote: In HTML or JSON, new formats need new parsers, which must be written by someone. Exactly. The point is if you have a generic model you have a generic parser. Right. HTML doesn't have a generic semantic model. JSON doesn't either, nor does XML. These are all data models. But all can be used to represent a generic semantic model, such as RDF. If there were a generic semantic model established with JSON syntax (RDF/ JSON?), we could convert microformats to it just as easily as we can convert microformats to RDF/XML, but I don't know of any such model, and microformats themselves certainly aren't that model. Elias is coming from an RDF background, and microformats simply aren't RDF, and they never will be. And that's a good thing. If what you want is RDF, just use RDF. The issue isn't really microformats vs. RDF (except as RDF provides a model), but microformats vs. RDFa. I don't think the issue is vs. at all. The two approaches solve different problems, are interoperable, and collectively improve the semantics of the web. It's all good. It's just not all the same. And the differences are a good thing. Both microformats and RDFa are addressing the exact same use cases and requirements (augmenting visible content with structured data). I don't think the use cases and requirements are the same at all, and I hope they never are or we're just doing redundant work here. RDFa's use cases include a generic semantic model. Microformats do not. Microformats have a requirement of making publishing as easy as possible to maximize adoption. RDFa does not share this requirement. These are two different efforts that will lose usefulness if merged into one. 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. I don't think that's a problem. 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. The RDF community seems like an obvious choice. I hope the various attempts at marking up the RDF model in HTML syntax work out well, but I don't think that should become a goal of this community. Moreover, the need to write dedicate code for each new microformat will also present serious scalability problems. So then microformats won't scale quickly. That's okay. RDF can scale quickly while microformats are more accessible to HTML publishers. We can build inter-op tools and everyone can be happy. 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. Right, so if you want a semantic model at the heart of your HTML markup, there's one already developed in RDFa. Or you could develop another. But microformats can not have a semantic model beyond HTML without becoming more cumbersome to HTML publishers, and that's something we should avoid. From my perspective, all of these attempts to make microformats more generalizable are sort of like telling people who are doing math on their fingers that they should stop because that won't scale. That's true, but they don't want it to scale right now. They just want to solve a simple problem using familiar tools. When they get to calculus, they'll pull out the calculator. I don't want to see microformats turned into a calculator while there are plenty of finger-math problems left to be solved. So while it might be comforting to dismiss RDFa and it's not our problem, I don't think it's good strategy. A good strategy toward what end? I think Elias has a problem that microformats are not intended to solve. What he wants to do is have a generic semantic model that anyone can use with any type of data, and put it in HTML. What microformats are intended to do is provide specific semantic models, not just /in/ HTML, but using the familiar tools of HTML as much as possible. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
From: Scott Reynen [EMAIL PROTECTED] So while it might be comforting to dismiss RDFa and it's not our problem, I don't think it's good strategy. A good strategy toward what end? I think Elias has a problem that microformats are not intended to solve. What he wants to do is have a generic semantic model that anyone can use with any type of data, and put it in HTML. What microformats are intended to do is provide specific semantic models, not just /in/ HTML, but using the familiar tools of HTML as much as possible. That's right, I think that what RDFa does is hint at realising the potential that microformats (in general) offer (to institutions), which 'microformats.org' with its inherent (and probably valid) limitations stops short of. Maybe, thinking of RDFa as microformats (in general) and microformats.org/microformats as microfortmatted-objects (in particular) might help understand this relationship better. S. Sriram ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
Why should RDFa get to mooch of the reputation that microformats has developed over the last 24 months? That reputation was developed by a lot of hard work by a lot of people (and really hard work by a few). What has RDFa brought to the table? Like microformats, RDFa wants to carry inline machine readable data with human readable data. Beyond this? It models data in a way that no one uses, to solve problems no one has, in a way that no one can find a use for [1][2]. 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. Regards, etc... David [1] http://www.google.com/search?hl=enq=rdf+applicationsbtnG=Google+Search [2] http://programmableweb.com/apis On 12/6/06, S. Sriram [EMAIL PROTECTED] wrote: That's right, I think that what RDFa does is hint at realising the potential that microformats (in general) offer (to institutions), which 'microformats.org' with its inherent (and probably valid) limitations stops short of. Maybe, thinking of RDFa as microformats (in general) and microformats.org/microformats as microfortmatted-objects (in particular) might help understand this relationship better. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
Some clarification: Isn't microformats more than one microformat? And what is a microformat? I thought a microformat was a specific collection of defined names and structure defined by a rigorous process of market research intended to consider pervasive use of semantic html in order to increase data fidelity of HTML-borne data widely distributed on the web. When people mention microformats they often are referring to the use of semantic html to increase data fidelity. This is extremely confusing because a microformat, or Microformat, is something more than any use of semantic html, it's a specific use to represent specific data. That is to say that the word microformats does not refer to a technique of data representation. Microformats are not a general extension mechanism, and such language is very confusing, and harmful to discussion. The general extension mechanism is to publish data using the best semantic techniques available, currently via class,rel,profile... The fact that microformats use these means doesn't somehow turn microformats into a technique for doing so. Vendors, authors, or anyone, can use the same techniques to raise proprietary data fidelity in HTML, but that doesn't turn them into a microformat. Data formats using these techniques achieve candidacy as a microformat when their use is widespread. Talk of general microformats doesn't make sense. Talk of microformats as technique also does not make sense. Talk of microformats as a group makes sense, but only when it refers to more than one actual microformat. When applied to people, Microformateers is probably better. Ryan, Thanks for helping to clear this up on the whatwg list, to some degree. Do we need to be more protective of our vocabulary? -Ben P.S. The definition I've given is what I understand microformats to be. AFAIK, there is no official definition, which may be contributing to the splintering of our vocabulary and mindshare. If I'm wrong I'm sure someone will correct me. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats
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 microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
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? I'm not sure what you mean. A design pattern is a technique, which is separate from what a microformat is. A microformat is an application of several techniques to a specific end. When some techniques prove successful, they become patterns. The techniques are means for generalized extensions, while a microformat is a specific application of those techniques for a specific extension. Microformats exhibit emergent characteristics from wide usage on the web; this characteristic means that these formats only exist because they have already scaled --even before they were borne. So I guess I'm not sure what the concern for scaling is. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Comments from IBM/Lotus rep about Microformats
For those on this list who are not following [whatwg], here is an interesting thread about inability to use Microformats: http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-December/00 8462.html I wonder if his issues can be addressed? -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
On 12/5/06, Mike Schinkel [EMAIL PROTECTED] wrote: For those on this list who are not following [whatwg], here is an interesting thread about inability to use Microformats: http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-December/00 8462.html I wonder if his issues can be addressed? I think the only way it can be addressed is with some effort to harmonize microformats and RDFa, which is not going to happen for what seem to me largely political reasons. The fact that we can't have a title property in hCite is already evidence of the practical problems that will result without such an effort. FWIW. Elias is an engineer (who writes code; rep sounds to me more marketing, but maybe tha's just me). Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
On 5 Dec 2006, at 11:30, Mike Schinkel wrote: For those on this list who are not following [whatwg], here is an interesting thread about inability to use Microformats: http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006- December/00 8462.html I wonder if his issues can be addressed? I'm not sure if they can, or not here at least. What I get from his message is not a problem with any specific Microformat, but that IBM finds the class/rel/rev/profile extension mechanism of HTML too limiting for their needs. In particular, he gives an example of ‘customers submitting their own microformats’, which is not the same as what we refer to as ‘microformats’ at all. In fact, such broad user-defined formats sounds distinctly out-of-scope of our efforts. If handling a large number of discrete user submitted bespoke formats is IBM's goal on their project, it's comprehensible that the extension mechanisms in HTML probably are inappropriate. Therefore, I think they're taking the right path in asking the WHATWG for a more suitable mechanism for them and their goal, but it doesn't really expose any problems with well specified microformats here. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
From: Mike Schinkel [EMAIL PROTECTED] http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-December/00 8462.html I wonder if his issues can be addressed? How about a distributed parser-discovery service More specifically a YADIS discovered JSON returning uf-specific parser: 1. Place an entry on the uf-authored page detailing the ufs-used meta name=ufs-used content=hreveiew hatom hwidget / 2. Place a yadiservices discovery pointer to where parser(s) maybe found, (on the same uf-authored page) meta name=ufs-used content=hreveiew hatom hwidget / meta http-equiv=X-YADIS-Location content=http://www.blahblah.com/path/to/yadis-file; / 3. add parser service data to the (existing) yadis file pointed to within the uf-authored page. ?xml version=1.0 encoding=UTF-8? xrds:XRDS xmlns:xrds=xri://$xrds xmlns=xri://$xrd*($v*2.0)XRD Service Typehttp://openid.net/signon/1.0/Type URIhttp://www.livejournal.com/openid/server.bml/URI /Service Service Typehttp://microformats.org/hreview/1.0/Type URIhttp://www.blah.com/path/to/uf2json-parser/URI /Service Service Typehttp://mysite.com/hwidget/1.0/Type URIhttp://www.mysite.com/path/to/uf2json-parser/URI /Service /XRD/xrds:XRDS 4. ..domain../path/to/uf2json-parser is a REST-call that is passed a 'uf-snippet' and returns a JSON object. Browsers that are uf-aware would call the parser with the uf-snippet, and than hand of the JSON to the storing module. CONS: The parser needs to be 'hosted', incurring bandwidth costs. PROS: Roll your own microformat and parser - or - *leave your html as is and just build a parser for it and point tothe parser from within the page.* S. Sriram ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
On Dec 5, 2006, at 10:48 AM, S. Sriram wrote: From: Mike Schinkel [EMAIL PROTECTED] http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006- December/00 8462.html I wonder if his issues can be addressed? Ian said: class, rel, and profile are the extension mechanism for HTML And Elias said: We have tried using microformats as an extension mechanism for HTML That response confuses the issues here. Ian pointed out the only allowed methods of extending HTML and said that microformats use these methods. That Elias is unsatisfied with these methods is a problem with HTML, not with microformats. We're not in charge of HTML here. How about a distributed parser-discovery service More specifically a YADIS discovered JSON returning uf-specific parser: 1. Place an entry on the uf-authored page detailing the ufs-used meta name=ufs-used content=hreveiew hatom hwidget / As Ian mentioned in the message Elias responded to, HTML already has this functionality with profile headers: http://microformats.org/wiki/profile-uris 2. Place a yadiservices discovery pointer to where parser(s) maybe found, (on the same uf-authored page) meta name=ufs-used content=hreveiew hatom hwidget / meta http-equiv=X-YADIS-Location content=http:// www.blahblah.com/path/to/yadis-file / 3. add parser service data to the (existing) yadis file pointed to within the uf-authored page. ?xml version=1.0 encoding=UTF-8? xrds:XRDS xmlns:xrds=xri://$xrds xmlns=xri://$xrd*($v*2.0)XRD Service Typehttp://openid.net/signon/1.0/Type URIhttp://www.livejournal.com/openid/server.bml/URI /Service Service Typehttp://microformats.org/hreview/1.0/Type URIhttp://www.blah.com/path/to/uf2json-parser/URI /Service Service Typehttp://mysite.com/hwidget/1.0/Type URIhttp://www.mysite.com/path/to/uf2json-parser/URI /Service /XRD/xrds:XRDS 4. ..domain../path/to/uf2json-parser is a REST-call that is passed a 'uf-snippet' and returns a JSON object. Browsers that are uf-aware would call the parser with the uf-snippet, and than hand of the JSON to the storing module. CONS: The parser needs to be 'hosted', incurring bandwidth costs. PROS: Roll your own microformat and parser - or - *leave your html as is and just build a parser for it and point tothe parser from within the page.* What you've described above is a process for converting all microformats to JSON, but that doesn't really solve the problem Elias described. It just changes the format. Each individual parser still needs to figure out what the JSON means, where before they had to figure out what the HTML means. In HTML or JSON, new formats need new parsers, which must be written by someone. Elias is coming from an RDF background, and microformats simply aren't RDF, and they never will be. And that's a good thing. If what you want is RDF, just use RDF. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
From: Scott Reynen [EMAIL PROTECTED] 2. Place a yadiservices discovery pointer to where parser(s) What you've described above is a process for converting all microformats to JSON, but that doesn't really solve the problem Elias described. It just changes the format. Each individual parser still needs to figure out what the JSON means, where before they had to figure out what the HTML means. In point of fact it exactly solves elias's problem in somewhat the same way that inline RDFa does. Because of the key-value pairs retuned by JSON. Take Elias's hCard example [1] with the need for additional attributes i.e. blog-url, activity-url etc. and the inability to 'add new properties' to an existing microformat. In the distributed parser model, the returned JSON would allow all uf-aware-browser-apps to look only for hCard data and allow 'uf-aware-special-browser-apps' to seek out the additional attributes i.e. blog-url etc. satisfying elias's need. In other words by looking at parsing/rendering as two seperate and distinct steps, with ditributed parsing one can accomodate 'generic' formats and 'custom' formats and one can accomodate 'generic' rendering and 'custom' rendering. One could also in theory extend the YADIS service to offer a uf-rendering service, so a browser could look at uf-authored page, send the uf-snippet to the 'discoverd' uf2json parser, and than send the json to the discovered 'uf-json-renderer/storer'.etc. [1] http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-December/008500.html S. Sriram ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
