As seen on JDEV today, Peter has forwarded a discussion that happened on the microformats.org mailing list to the Jabber community. Apparently this dude in the MF camp heard that the Adium project was working on standardizing an IM chat log format that *gasp* didn’t use microformats! (Melodrama mine.) Of course in the Jabber world we would do it in XML and just define a common set of terms and publish it as a JEP. Happens all the time.
I’m sorry, I don’t get where these MF guys are going. It seems to me that they are trying to make the web more semantic. Fine and good. Took me a while to grok and then find a concrete example. Here’s a draft spec for “adr” or physical address information.
<div class="adr"> <div class="street-address">665 3rd St.</div> <div class="extended-address">Suite 207</div> <span class="locality">San Francisco</span>, <span class="region">CA</span> <span class="postal-code">94107</span> <div class="country-name">U.S.A.</div> </div>
Correct me if I’m wrong, but isn’t this just a superfluous layer of XHTML on top of XML? What they have done is set up a straw man argument–a world in which XML does not exist–and declared there is a problem that they must solve by “building upon existing and widely adopted standards“.
Some other choice marketing-speak used on the site:
Designed for humans first and machines second
highly correlated with semantic XHTML
[using principles of] modularity / embeddability
All of these things perfectly describe XML. They go on to say what Microformats are not, and essentially you can translate the statements as “not XML”. So which is it guys?
Let me provide an equivalent XML (XMPP actually) example:
<ADR>
<WORK/>
<EXTADD>Suite 600</EXTADD>
<STREET>1899 Wynkoop Street</STREET>
<LOCALITY>Denver</LOCALITY>
<REGION>CO</REGION>
<PCODE>80202</PCODE>
<CTRY>USA</CTRY>
</ADR>
Ok. Does the above semantically describe a physical address? Is it easily parseable by both humans and machines? Is it a simple? Built on existing standard? An open way to think about data? It’s even less to type!
You just gotta love standards. There are so freakin’ many to choose from!
Problem is, that won’t render as HTML without XSL.
Microformats are supposed to address that.
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.
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.
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.
And yay for broken feedback forms
If something is broken, let me know via jabber or email please.
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
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
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.
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.
Chris, I think we’ll have to agree to disagree.
[...] 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. [...]