Re: [uf-discuss] Definition of Microformats
On 28/02/07, Angus McIntyre [EMAIL PROTECTED] wrote: To expand briefly on (b) above, imagine a naive developer who has heard about the wonderful new microformat hThing. They find a Thing marked with the class=hThing, open it up in a text editor and say Ah, so that's how it's done.. They then reproduce the structure in their documents. Unknown to them, the page was drawn up by an early adopter using their notion of what hThing might later turn out to be. When ThingBot, the Thing Crawler (tm) totally ignores Mr/Ms Naive Developer's page, s/he will be frustrated. But I used hThing! They should have read the spec, you say. In an ideal world, they would, but in a less-than-ideal world, there's still an interest in trying to encourage as many examples of good practice as possible, for the benefit of those who don't read specs (and - by extension - for the benefit of everyone who stands to profit from use of microformats, which is all of us). Just as a slight aside - this tends to be what happens anyway. Even when learning and writing simple HTML, most people do that by looking at examples in the wild. There's only a small percentage of people using (X)HTML 1.0, for example, that ever read the spec cover to cover. Most later discover their problems with validation and use error messages to point them in the right direction. So I think my vague point is that people will learn from examples anyway - whether they be based on good examples, out-dated examples, or simply wrong/incorrectly implemented examples of current microformats specifications. There's a certain degree of education that'll have to happen with adoption. Having said that - yes, I do agree that we should encourage as many accurate implementations as possible, of course! -- Frances Berriman http://fberriman.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Definition of Microformats
On 2/27/07, Angus McIntyre [EMAIL PROTECTED] wrote: At 18:57 -0600 27.02.2007, Scott Reynen wrote: On Feb 27, 2007, at 5:15 PM, Angus McIntyre wrote: We're trying to model publishing behaviors, not change them and certainly not restrict them. If someone publishes something that doesn't match a microformat standard, parsers should be able to deal with that by checking for valid data. We should be actively *encouraging* experimentation with publishing meaningful HTML. Meaningful HTML is never litter; it all adds to a more semantic web. Meaningfulness is not defined by microformats. We have no monopoly on these ideas, and pretending we do is harmful. While that might encourage parser builders to make their parsers robust, it's probably not a good thing overall. It is a good thing overall. What's not a good thing is this notion that people need some sort of approval from us to use more descriptive markup. Moving away from the specific case of hRelease, I would say the following: 1. Early adopters who want to use structured markup should be encouraged, not least because that generates 'examples in the wild' that will guide the standards process. I think we're in agreement on that point. 2. Using the likely name of a microformat 'prematurely' or inconsistently is problematic (although the problems are not necessarily very serious) for a few reasons including: hRelease is just an example. My point, just to underline this a little bit more, is that we've already got a term semantic (x)html [1] that covers using classes to mark up semantic elements. microformats are semantic (x)html plus the process and rules (see [1] again). This is probably something that needs to be stressed more, otherwise the 'brand' is going to be diluted. Why is this bad? Because it renders near meaningless all the work that has gone on here to make sure we've got everything just right -- we'll see people reusing names to mean different things, making up new names to define the same thing, and so on and so forth. Regards, etc... David [1] http://microformats.org/wiki/semantic-xhtml-design-principles#Semantic_XHTML_and_Microformats -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://blogmatrix.blogmatrix.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Definition of Microformats
On Feb 27, 2007, at 9:43 PM, Angus McIntyre wrote: I think I started off slightly on the wrong foot, because I wrongly assumed that hRelease was something that had already been raised in this community. In fact, it appears to have emerged at http:// www.socialtext.net/hRelease without ever being listed as a proposed or possible microformat at microformats.org. I'm certainly not arguing that only we should be allowed to propose or define microformats. I am arguing, however, that there's some value to 'interim' names that can be used by enthusiastic early adopters before a standard is defined. Moving away from the specific case of hRelease, I would say the following: 1. Early adopters who want to use structured markup should be encouraged, not least because that generates 'examples in the wild' that will guide the standards process. I think we're in agreement on that point. Great. 2. Using the likely name of a microformat 'prematurely' or inconsistently is problematic (although the problems are not necessarily very serious) for a few reasons including: a. Even if robots can handle non-compliant samples (as they should), it makes them do unnecessary work and, Handling non-compliant input will always be necessary, because publishers will always make mistakes. That's just part of writing a microformats parser. It's not a particularly hard part either. If you can't figure out what to do with something, you just don't do anything with it. b. Because much HTML is learned by example, we have an interest in promoting a higher proportion of 'good' examples, The solution to the proliferation of bad formats is to make the formats better. People will use the better formats because they're better, and the bad formats will gradually disappear. c. In general, the usefulness of a microformat is 'diluted' if the proportion of conformant samples is low compared to the proportion of non-conformant samples. How so? The only hCard's validity I care about is the one I'm trying to use. If the rest of the web were full of invalid hCards, that wouldn't make the one I'm trying to use any less useful. To expand briefly on (b) above, imagine a naive developer who has heard about the wonderful new microformat hThing. They find a Thing marked with the class=hThing, open it up in a text editor and say Ah, so that's how it's done.. They then reproduce the structure in their documents. Unknown to them, the page was drawn up by an early adopter using their notion of what hThing might later turn out to be. When ThingBot, the Thing Crawler (tm) totally ignores Mr/ Ms Naive Developer's page, s/he will be frustrated. But I used hThing! They should have read the spec, you say. In an ideal world, they would, but in a less-than-ideal world, there's still an interest in trying to encourage as many examples of good practice as possible, for the benefit of those who don't read specs (and - by extension - for the benefit of everyone who stands to profit from use of microformats, which is all of us). I see two solutions to this problem: 1) Discourage Mr Naive Dev from implementing the spec until it has been blessed for use 2) Continuously improve the spec, and encourage Mr Naive Dev to update when the spec improves I think 2 is clearly better, not least because it indirectly takes care of 1, as early drafts are revised much more frequently, so publishers will be more hesitant to use them if they're not prepared to frequently update. 3. Suggesting an alternative name that could be used in place of as- yet-undefined microformats may avoid these problems and, as a bonus, allow more efficient collection of real-world examples. As-yet-undefined microformats should really have no names, though we often name things before we have any reason to. I'm all for using alternative names, and I suggest common English for that. If we're talking about a thing, let's use class=thing. If we're talking about a song, let's use class=song. Then when we finally establish a microformat for songs, we can call it something relatively unique like hSong and avoid any name conflict. I think this is pretty much what we already do, except we've lately grown fond of that h and started attaching it to common words for no apparent reason. So let's stop doing that. While I probably don't feel strongly enough about this to volunteer to be burned at the stake for my beliefs on the subject, I think that suggesting the use of 'experimental' microformat names to preshadow a future microformat would not harm and might possibly help. And that's all I really wanted to say. Sorry if I came off as burning you at the stake. All of the recent discussion of governance has me worried people are delegating far too much authority (and too much responsibility) to this community. Peace, Scott
[uf-discuss] Definition of Microformats
I've been looking at this [1][2] and I think ... maybe ... that there's something missing. Are not microformats something that is created by the microformats process? The reason I ask is that someone's announced hRelease today [3] using the microformats name and symbol. Regards, etc... [1] http://microformats.org/about/ [2] http://microformats.org/wiki/what-are-microformats [3] http://www.psnetwork.org.nz/blog/2007/02/27/microformats-govt-release/ -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://blogmatrix.blogmatrix.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Definition of Microformats
On 2/27/07, David Janes [EMAIL PROTECTED] wrote: The reason I ask is that someone's announced hRelease today [3] using the microformats name and symbol. [3] http://www.psnetwork.org.nz/blog/2007/02/27/microformats-govt-release/ Reading closely, it's not an announcement of hRelease itself, but the announcement of an attempted use of hRelease to mark up a press release[1]. It also notes that hRelease is not even a draft, and links to the microformats.org process... -cks [1] Writing that made my head hurt. -- Christopher St. John http://artofsystems.blogspot.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Definition of Microformats
On Tue, February 27, 2007 5:45 pm, Christopher St John wrote: On 2/27/07, David Janes [EMAIL PROTECTED] wrote: ... someone's announced hRelease today [3] using the microformats name and symbol. [3] http://www.psnetwork.org.nz/blog/2007/02/27/microformats-govt-release/ Reading closely, it's not an announcement of hRelease itself, but the announcement of an attempted use of hRelease to mark up a press release[1]. It also notes that hRelease is not even a draft, and links to the microformats.org process... If people start using microformats before they've even made it into draft stage, that's going to litter the web landscape with parser-breaking instances of things that don't conform to whatever the final standard turns out to be, but which are marked as if they did. While that might encourage parser builders to make their parsers robust, it's probably not a good thing overall. Would it be worth proposing the 'x' prefix for the early adopters who feel compelled to use a microformat before it's done, i.e. 'xRelease' or 'xhRelease' for early iterations of what we hope may one day become 'hRelease'? That would let people play around with stuff (and generate 'examples in the wild') without posing problems for future generations. Once a given proposal reaches draft stage, the class could even be versioned, i.e. div class=xRelease01. This might permit anyone who cared enough to attempt transforming old versions into versions that conformed to the final spec. Angus ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Definition of Microformats
At 18:57 -0600 27.02.2007, Scott Reynen wrote: On Feb 27, 2007, at 5:15 PM, Angus McIntyre wrote: We're trying to model publishing behaviors, not change them and certainly not restrict them. If someone publishes something that doesn't match a microformat standard, parsers should be able to deal with that by checking for valid data. We should be actively *encouraging* experimentation with publishing meaningful HTML. Meaningful HTML is never litter; it all adds to a more semantic web. Meaningfulness is not defined by microformats. We have no monopoly on these ideas, and pretending we do is harmful. While that might encourage parser builders to make their parsers robust, it's probably not a good thing overall. It is a good thing overall. What's not a good thing is this notion that people need some sort of approval from us to use more descriptive markup. That wasn't what I was suggesting, and I understand and agree with your points above. I think I started off slightly on the wrong foot, because I wrongly assumed that hRelease was something that had already been raised in this community. In fact, it appears to have emerged at http://www.socialtext.net/hRelease without ever being listed as a proposed or possible microformat at microformats.org. I'm certainly not arguing that only we should be allowed to propose or define microformats. I am arguing, however, that there's some value to 'interim' names that can be used by enthusiastic early adopters before a standard is defined. Moving away from the specific case of hRelease, I would say the following: 1. Early adopters who want to use structured markup should be encouraged, not least because that generates 'examples in the wild' that will guide the standards process. I think we're in agreement on that point. 2. Using the likely name of a microformat 'prematurely' or inconsistently is problematic (although the problems are not necessarily very serious) for a few reasons including: a. Even if robots can handle non-compliant samples (as they should), it makes them do unnecessary work and, b. Because much HTML is learned by example, we have an interest in promoting a higher proportion of 'good' examples, c. In general, the usefulness of a microformat is 'diluted' if the proportion of conformant samples is low compared to the proportion of non-conformant samples. To expand briefly on (b) above, imagine a naive developer who has heard about the wonderful new microformat hThing. They find a Thing marked with the class=hThing, open it up in a text editor and say Ah, so that's how it's done.. They then reproduce the structure in their documents. Unknown to them, the page was drawn up by an early adopter using their notion of what hThing might later turn out to be. When ThingBot, the Thing Crawler (tm) totally ignores Mr/Ms Naive Developer's page, s/he will be frustrated. But I used hThing! They should have read the spec, you say. In an ideal world, they would, but in a less-than-ideal world, there's still an interest in trying to encourage as many examples of good practice as possible, for the benefit of those who don't read specs (and - by extension - for the benefit of everyone who stands to profit from use of microformats, which is all of us). 3. Suggesting an alternative name that could be used in place of as-yet-undefined microformats may avoid these problems and, as a bonus, allow more efficient collection of real-world examples. While I probably don't feel strongly enough about this to volunteer to be burned at the stake for my beliefs on the subject, I think that suggesting the use of 'experimental' microformat names to preshadow a future microformat would not harm and might possibly help. And that's all I really wanted to say. ... We should be absolutely clear that no one needs permission to change their HTML markup. Amen to that. Angus ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
