Comments on: Microformats — please explain this one to me! http://halr9000.com/article/322 (powershell & other stuff) Mon, 06 Oct 2008 18:58:18 +0000 http://wordpress.org/?v=2.6 By: Milk’s Blog » Offline Jabber standards http://halr9000.com/article/322#comment-2381 Milk’s Blog » Offline Jabber standards Thu, 24 Aug 2006 12:32:16 +0000 http://halr9000.com/article/322#comment-2381 [...] Back in the day, I suggested on the Jabber standards mailing list that it might be an idea to have a open chat log format that would be interoperable between clients. Queue a fairly heated debate (I was 19 and even more hot headed than I am the now ;) with a few devs about the issue with arguments such as because it’s client side that it was something the Jabber Software Foundation should get involved with and that to conform to a standardised open log format would be admitting that their client was less than good (their client already conformed to XMPP; does that logic not mean that their lack of being able to create a world beating IM/presence protocol mean they’ve failed already?). These days it’s part of a JEP (not widely implemented yet, although you could say that of most JEPs) and there have been recent discussions about the issue and the best way to go about it. It would have happened one day anyway, but I still find it infuriating how many dots that need obvious connecting there are out there. [...] [...] Back in the day, I suggested on the Jabber standards mailing list that it might be an idea to have a open chat log format that would be interoperable between clients. Queue a fairly heated debate (I was 19 and even more hot headed than I am the now ;) with a few devs about the issue with arguments such as because it’s client side that it was something the Jabber Software Foundation should get involved with and that to conform to a standardised open log format would be admitting that their client was less than good (their client already conformed to XMPP; does that logic not mean that their lack of being able to create a world beating IM/presence protocol mean they’ve failed already?). These days it’s part of a JEP (not widely implemented yet, although you could say that of most JEPs) and there have been recent discussions about the issue and the best way to go about it. It would have happened one day anyway, but I still find it infuriating how many dots that need obvious connecting there are out there. [...]

]]> By: halr9000 http://halr9000.com/article/322#comment-2359 halr9000 Mon, 21 Aug 2006 18:42:57 +0000 http://halr9000.com/article/322#comment-2359 Chris, I think we'll have to agree to disagree. :) Chris, I think we’ll have to agree to disagree. :)

]]> By: Chris Messina http://halr9000.com/article/322#comment-2332 Chris Messina Thu, 17 Aug 2006 07:03:11 +0000 http://halr9000.com/article/322#comment-2332 As the "dude" who wrote the original message pointing out that *gasp* they weren't using an XHTML-based chat transcript format, I appreciate what you're saying but respectfully disagree. The points that you make are common and sound good, especially in the context of an XML-friendly universe. The gross majority of web developers and web designers, however, do not live in the XML world; they primarily deal with basic XHTML and CSS. In fact, the example that you cite w/r/t XMPP is fine in a very small, narrow field of view. If you consider the <a href="http://microformats.org/wiki/plain-old-xml-considered-harmful" rel="nofollow">need to multi-class objects</a>, you begin to see the value in XHTML class names and why <a href="http://microformats.org/wiki/namespaces-considered-harmful" rel="nofollow">namespacing is a bad idea</a>. Furthermore, XHTML is incredibly portable -- able to be used in nearly any application whereas one-off XML languages find very little support in the wild. Data portability is the thrust of the microformats effort; and it's a long term process using a <a href="http://microformats.org/wiki/process" rel="nofollow">community process</a> to develop its standards. We realize and accept that there will always be transitional XML dialects, but few if any will stick around longer than good ol' XHTML. As the “dude” who wrote the original message pointing out that *gasp* they weren’t using an XHTML-based chat transcript format, I appreciate what you’re saying but respectfully disagree.

The points that you make are common and sound good, especially in the context of an XML-friendly universe. The gross majority of web developers and web designers, however, do not live in the XML world; they primarily deal with basic XHTML and CSS.

In fact, the example that you cite w/r/t XMPP is fine in a very small, narrow field of view. If you consider the need to multi-class objects, you begin to see the value in XHTML class names and why namespacing is a bad idea.

Furthermore, XHTML is incredibly portable — able to be used in nearly any application whereas one-off XML languages find very little support in the wild.

Data portability is the thrust of the microformats effort; and it’s a long term process using a community process to develop its standards. We realize and accept that there will always be transitional XML dialects, but few if any will stick around longer than good ol’ XHTML.

]]> By: Richard http://halr9000.com/article/322#comment-2315 Richard Tue, 15 Aug 2006 16:06:49 +0000 http://halr9000.com/article/322#comment-2315 Personally I think its highly unlikely that normal users are going to be uploading their Jabber logs to the web, and even if they want to its far easier to just have an option in the users client for "Export to HTML" as users are very unlikely to be wanting to upload their entire log file, they will just want to upload snipets of it, and its far more user friendly to deal with that within the client than making the user edit the log file themselves for uploading it, thats assuming they even have the understanding to do that themselves. So as users are unlikely to be uploading the raw log files themselves it doesnt seem necessary to mandate that the log files have to use microformats. It makes far more sense to use something more HTML compatible for the export function. Personally I think its highly unlikely that normal users are going to be uploading their Jabber logs to the web, and even if they want to its far easier to just have an option in the users client for “Export to HTML” as users are very unlikely to be wanting to upload their entire log file, they will just want to upload snipets of it, and its far more user friendly to deal with that within the client than making the user edit the log file themselves for uploading it, thats assuming they even have the understanding to do that themselves.

So as users are unlikely to be uploading the raw log files themselves it doesnt seem necessary to mandate that the log files have to use microformats.

It makes far more sense to use something more HTML compatible for the export function.

]]> By: stpeter http://halr9000.com/article/322#comment-2298 stpeter Mon, 14 Aug 2006 15:58:54 +0000 http://halr9000.com/article/322#comment-2298 AFAICS, the microformats stuff is very much XHTML-centric because that community focuses on integration with the existing Web, whereas Jabber/XMPP is very much XML-centric because our community has built an alternative communications network. I want to make it "legal" (via JEP-0071) for people who care about microformats to include that kind of markup in XHMTL-IM messages as a connecting point between the Jabber world and the Web world. I'm not saying it's necessary for any Jabber client to support that, but they can if they want. Perhaps some experiments along these lines will lead to interesting results. In any case, I see no reason to discourage such experiments. /psa AFAICS, the microformats stuff is very much XHTML-centric because that community focuses on integration with the existing Web, whereas Jabber/XMPP is very much XML-centric because our community has built an alternative communications network. I want to make it “legal” (via JEP-0071) for people who care about microformats to include that kind of markup in XHMTL-IM messages as a connecting point between the Jabber world and the Web world. I’m not saying it’s necessary for any Jabber client to support that, but they can if they want. Perhaps some experiments along these lines will lead to interesting results. In any case, I see no reason to discourage such experiments. /psa

]]> By: Mike http://halr9000.com/article/322#comment-2296 Mike Mon, 14 Aug 2006 14:40:43 +0000 http://halr9000.com/article/322#comment-2296 I think it basically boils down to "do you want to put it on the web or not?" I wrote a slightly longer version of this argument here: http://volition.vee.net/archives/000670.html I think it basically boils down to “do you want to put it on the web or not?” I wrote a slightly longer version of this argument here: http://volition.vee.net/archives/000670.html

]]> By: halr9000 http://halr9000.com/article/322#comment-2282 halr9000 Sun, 13 Aug 2006 18:04:14 +0000 http://halr9000.com/article/322#comment-2282 If something is broken, let me know via jabber or email please. If something is broken, let me know via jabber or email please.

]]> By: ralphm http://halr9000.com/article/322#comment-2280 ralphm Sun, 13 Aug 2006 16:36:33 +0000 http://halr9000.com/article/322#comment-2280 And yay for broken feedback forms ;-) And yay for broken feedback forms ;-)

]]> By: ralphm http://halr9000.com/article/322#comment-2279 ralphm Sun, 13 Aug 2006 16:35:33 +0000 http://halr9000.com/article/322#comment-2279 I can understand why you would want something like microformats in the HTML world. Most HTML doesn't validate, so you can kiss XHTML and XML goodbye there. However, in the XMPP world, I don't see why you would want to markup messages with such information. We /have/ valid XML *and* a defined way to add additional data to a . You don't need the hack of microformats. And also, I believe XHTML-IM is meant for simple visually marking up chats (with emphasis, color), not anything else. I can understand why you would want something like microformats in the HTML world. Most HTML doesn’t validate, so you can kiss XHTML and XML goodbye there.

However, in the XMPP world, I don’t see why you would want to markup messages with such information. We /have/ valid XML *and* a defined way to add additional data to a . You don’t need the hack of microformats. And also, I believe XHTML-IM is meant for simple visually marking up chats (with emphasis, color), not anything else.

]]> By: Nolan Eakins http://halr9000.com/article/322#comment-2268 Nolan Eakins Sun, 13 Aug 2006 03:57:59 +0000 http://halr9000.com/article/322#comment-2268 You shouldn't even need XSL to render that in a web browser. CSS should be enough. You'll just have to be sure to declare how an element gets displayed. Possible CSS: ADR { display: block; border: solid 1px black; } ADR EXTADD, ADR STREET, ADR LOCALITY, ADR REGION, ADR PCODE, ADR CTRY { display: inline; } ADR STREET:after, ADR LOCALITY:after, ADR pcode:after { content: ","; } One problem is that the child elements MUST be in the order in which they'll be displayed, and there's nothing conditional about where commas go. XSL doesn't have this limitation, so it would be a better choice. All in all, browsers need to learn about namespaces and how to apply stylesheets to non-HTML elements. Microformats are just a technique to bridge that gap. You shouldn’t even need XSL to render that in a web browser. CSS should be enough. You’ll just have to be sure to declare how an element gets displayed.

Possible CSS:
ADR {
display: block;
border: solid 1px black;
}
ADR EXTADD, ADR STREET, ADR LOCALITY, ADR REGION, ADR PCODE, ADR CTRY {
display: inline;
}

ADR STREET:after, ADR LOCALITY:after, ADR pcode:after {
content: “,”;
}

One problem is that the child elements MUST be in the order in which they’ll be displayed, and there’s nothing conditional about where commas go. XSL doesn’t have this limitation, so it would be a better choice.

All in all, browsers need to learn about namespaces and how to apply stylesheets to non-HTML elements. Microformats are just a technique to bridge that gap.

]]> By: halr9000 http://halr9000.com/article/322#comment-2264 halr9000 Sun, 13 Aug 2006 01:07:43 +0000 http://halr9000.com/article/322#comment-2264 No, no, no! They are going about it the wrong way! You are right about the rendering, I know. What they should be doing is solving the XSL problem instead. Or, don't bother. Just do some sort of XHTML meta reference like this below, and then using the software that put it there (e.g. your blog or CMS software), generate the appropriate XHTML human-readable part. <pre><link rel="adr" type="text/xml" href="/microformats/adr.xml" name="Corporate office physical address" /></pre> No, no, no! They are going about it the wrong way! You are right about the rendering, I know. What they should be doing is solving the XSL problem instead. Or, don’t bother. Just do some sort of XHTML meta reference like this below, and then using the software that put it there (e.g. your blog or CMS software), generate the appropriate XHTML human-readable part.

<link rel="adr" type="text/xml" href="/microformats/adr.xml"
  name="Corporate office physical address" />
]]> By: Alex Jones http://halr9000.com/article/322#comment-2263 Alex Jones Sun, 13 Aug 2006 00:53:52 +0000 http://halr9000.com/article/322#comment-2263 Problem is, that won't render as HTML without XSL. Microformats are supposed to address that. Problem is, that won’t render as HTML without XSL.

Microformats are supposed to address that.

]]>