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
Re: [uf-discuss] Definition of Microformats
On Feb 27, 2007, at 5:15 PM, Angus McIntyre wrote: On 2/27/07, David Janes <[EMAIL PROTECTED]> wrote: 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. 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 idea prevents people from doing the sort of experiments that lead to a better understanding of HTML semantics and it makes them resent this community for its imaginary control over the web. Calling something a microformat that isn't really a microformat might be a problem, but it's a relatively low priority compared to discouraging publishers from using better markup. We should be absolutely clear that no one needs permission to change their HTML markup. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] rel-tag title as tag value
On Feb 27, 2007, at 4:38 PM, Mike Kaply wrote: This all points back to the original problem which I still haven't got a good explanation for. Microformats that require no custom changes to servers or web page: XFN hCard hCalendar hAtom hReview Address hResume xFolk Microformats that require specific settings on your web server, and access by the user to configure that web server if necessary and a very specific syntax that you might not be able to accomplish with your configuration: rel-tag Does anyone see the disconnect or just me? All rel-* microformats (e.g. XFN, rel-license, vote-links, even rel- nofollow) require something on the other end of the link. Most require just a document relevant to the microformat. rel-tag requires that document be (or appear to be) the index of a directory. All web servers allow directory indexing by default, so this does not require any special configuration. It just requires access to create files on the server, which is no different from what any other rel-* microformat requires. I think this requirement is more onerous with rel-tag primarily because there are a lot more documents involved in rel-tag than any of the other rel-* microformats, not really because it's a fundamentally different type of microformat. And this is apparently a widespread concern, but it will be easy to dismiss as an edge case until someone has documented a convincingly large number of real- world examples where rel-tag currently fails. This is the primary disconnect I see. I think this wiki page is a good place to start documenting tag space formats to see if the standard format (last path segment) identified in rel-tag falls short of the 80% mark: http://microformats.org/wiki/tag-space-formats Peace, Scott ___ 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. . 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] rel-tag title as tag value
Mike Kaply wrote: Microformats that require specific settings on your web server, and access by the user to configure that web server if necessary and a very specific syntax that you might not be able to accomplish with your configuration: rel-tag Don't forget it's also the only one that goes against the microformats mantra: "simple conventions for embedding semantic markup." It is neither markup, nor simple. Rather, it's not simple in the majority of cases. Regarding simplicity: 1. Linking to others' tagspace. Simple? Yes. Practical? Probably not. 2. Creating a physical directory for every tag I create. Simple? Yes. Tedious? You bet. Fully localizable with a full UTF-8 character set? Only if you want to escape them all. That'd be pretty. 3. URL rewriting. Practical? Very. Recommended? Yes. Simple? Certainly not. Low barrier to entry? I'd argue that anything requiring RegEx does not entail a low barrier to entry... therefore, not simple. I believe we all agree that a restful tagspace is best. I also think no one here suggests *requiring* a title if the tagspace is there. We are only requesting an alternative that is both "simple" and "markup." Something anyone can implement. James PS. Have you seen the emperor's lovely new clothes? ;-) PPS. If that counts as "snarky", call me out on it. It's meant in fun. ___ 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] rel-tag title as tag value
On 2/27/07, Scott Reynen <[EMAIL PROTECTED]> wrote: I'd say if you're restricted to using a single tag space, and you don't have enough control over that tag space to create directories (a functionality available on any server), you have an exceptional case not covered by rel-tag. But there's no reason you need to restrict your markup to what's covered by rel-tag. If there's some alternative format to the URLs in your mandatory tag space, just adapt the tools you want to look for your format. Almost all of them are open source. This all points back to the original problem which I still haven't got a good explanation for. Microformats that require no custom changes to servers or web page: XFN hCard hCalendar hAtom hReview Address hResume xFolk Microformats that require specific settings on your web server, and access by the user to configure that web server if necessary and a very specific syntax that you might not be able to accomplish with your configuration: rel-tag Does anyone see the disconnect or just me? Mike Kaply ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[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] rel-tag title as tag value
On Feb 27, 2007, at 2:14 PM, Mike Kaply wrote: On 2/26/07, Charles Iliya Krempeaux <[EMAIL PROTECTED]> wrote: You could create a directory for each tag. For example... http://dogear.example.com/html/tag/collaboration/ http://dogear.example.com/html/tag/programming/ http://dogear.example.com/html/tag/linguistics/ Again server changes I'd say if you're restricted to using a single tag space, and you don't have enough control over that tag space to create directories (a functionality available on any server), you have an exceptional case not covered by rel-tag. But there's no reason you need to restrict your markup to what's covered by rel-tag. If there's some alternative format to the URLs in your mandatory tag space, just adapt the tools you want to look for your format. Almost all of them are open source. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] rel-tag title as tag value
On 2/27/07, Mike Kaply <[EMAIL PROTECTED]> wrote: Incidentally, has anyone that worked on rel-tag ever read this: http://www.w3.org/TR/webarch/#uri-opacity --- i would agree that you can't infer information of just ANY URL, but because the publisher has EXPLICITLY added the rel-tag, i would say that you can. The example of: http://weather.example.com/oaxaca certainly LOOKS like it is about oaxaca, but you can't safely make that assumption. If a published adds additional information and excplicitly says this is a TAG about oaxaca, then they are asserting something about the link. No matter how you slice it, you have to trust that the user is representing the metadata correctly, wether it is part of the URL, the @title, the nodeValue or somewhere else. If you can't trust the publisher with the a tag and tagspace, why would you trust them with the data elsewhere? -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] rel-tag title as tag value
On 2/26/07, Charles Iliya Krempeaux <[EMAIL PROTECTED]> wrote: You could create a directory for each tag. For example... http://dogear.example.com/html/tag/collaboration/ http://dogear.example.com/html/tag/programming/ http://dogear.example.com/html/tag/linguistics/ Again server changes Incidentally, has anyone that worked on rel-tag ever read this: http://www.w3.org/TR/webarch/#uri-opacity Mike Kaply ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
