Category: Technology

Categories
Technology

What’s shorter than 140 characters?

What can possibly top Twitter and its immediacy, as well as brevity of contact? I think we found out this week, with Google Wave. Tim O’Reilly describes it as what email would be like if invented today. My first reaction, and judging from other responses, is that it’s remarkably similar to Ray Ozzie’s Groove, before Groove became little more than a ghost appendage to Microsoft.

Folks immediately started rumbling about “twitter killer”, but I look at it and see the answer to the question, “What can beat out 140 characters?” The answer is, evidently, echoed keystrokes as people make them.

I watched the presentation video (thank you for that, Google). Technologically, Google Wave is intriguing. What was also intriguing was Google’s strong emphasis on HTML5 during the presentation, including a reference to additions to the HTML5 spec. But the part that caught my attention is that Wave is actually echoing keystrokes. I can imagine the following discussion, happening live:

A: I just saw the demo of Google Wave …

B: Oh, yeah, that was terrific

A:….and it sucked

B: Oh, um, well I thought…

A: You liked it! Are you…

B: …it was innovative

A: …cracked?

Google Wave is ADD heroin.

I was thinking about Google Wave yesterday, as I ran the gauntlet that is known as Watson Street, here in St. Louis. As I dodged little old ladies who pull into the road without looking, and the 30 something guy who cut me off when he should have yielded, or contemplated the new ding in my car from some mother’s precious child opening his or her car door too hard, and too wide, I began to appreciate what Twitter, Google Wave, Blogging, Facebook, and other social media are: real life alternative communities.

Because in real life, we’re all pricks.

Categories
RDF Standards XHTML/HTML

A Loose Set of Notes on RDFa, XHTML, and HTML5

There’s been a great deal of discussion about RDFa, HTML5, and microdata the last few days, on email lists and elsewhere. I wanted to write down notes of the discussions here, for future reference. Those working issues with RDFa in Drupal 7 should pay particular attention, but the material is relevant to anyone incorporating RDFa.

Shane McCarron released a proposal for RDFa in HTML4, which is based on creating a DTD that extends support for RDFa in HTML4. He does address some issues related to the differences in how certain data is handled in HTML4 and XHTML, but for the most part, his document refers processing issues to the original RDFaSyntax document.

Philip Taylor responded with some questions, specifically about how xml:lang is handled by HTML5 parsers, as compared to XML parsers. His second concern was how to handle XMLLiteral in HTML5, because the assumption is that RDFa extractors in JavaScript would be getting their data from the DOM, not processing the characters in the page.

“If the object of a triple would be an XMLLiteral, and the input to the processor is not well-formed [XML]” – I don’t understand what that means in an HTML context. Is it meant to mean something like “the bytes in the HTML file that correspond to the contents of the relevant element could be parsed as well-formed XML (modulo various namespace declaration issues)”? If so, that seems impossible to implement. The input to the RDFa processor will most likely be a DOM, possibly manipulated by the DOM APIs rather than coming straight from an HTML parser, so it may never have had a byte representation at all.

There’s a lively little sub-thread related to this one issue, but the one response I’ll focus on is Shane, who replied, RDFa does not pre-suppose a processing model in which there is a DOM. The issue of xml:lang is also still under discussion, but I want to move on to new issues.

While the discussion related to Shane’s document was ongoing, Philip released his own first look at RDFa in HTML5. Concern was immediately expressed about Philip’s copying of some of Shane’s material, in order to create a new processing rule section. The concern wasn’t because of any issue to do with copyright, but the problems that can occur when you have two sets of processing rules for the same data and the same underlying data model. No matter how careful you are, at some point the two are likely to diverge, and the underlying data model corrupted.

Rather than spend time on Philip’s specification directly at this time, I want to focus, instead, on a note he attached to the email entry providing the link to the spec proposal. In it he wrote:

There are several unresolved design issues (e.g. handling of case-sensitivity, use of xmlns:* vs other mechanisms that cause fewer problems, etc) – I haven’t intended to make any decisions on such issues, I’ve just attempted to define the behaviour with sufficient detail that it should make those issues visible.

More on case sensitivity in a moment.

Discussion started a little more slowly for Philip’s document, but is ongoing. In addition, both Philip and Manu Sporney released test suites. Philip’s is focused on highlighting problems when parsing RDFa in HTML as compared to XHTML; The one that Manu posted, created by Shane, focused on a basic set of test cases for RDFa, generally, but migrated into the RDFa in HTML4 document space.

Returning to Philip’s issue with case sensitivity, I took one of Shane’s RDFa in HTML test cases, and the rdfquery JavaScript from Philip’s test suit, and created pages demonstrating the case sensitivity issue. One such is the following:

<!DOCTYPE HTML PUBLIC "-//ApTest//DTD HTML4+RDFa 1.0//EN" "http://www3.aptest.com/standards/DTD/html4-rdfa-1.dtd">
<html
xmlns:t="http://test1.org/something/"
xmlns:T="http://test2.org/something/"
xmlns:dc="http://purl.org/dc/elements/1.1/">
<head>
<title>Test 0011</title>
</head>
<body>
<div about="">
Author: <span property="dc:creator t:apple T:banana">Albert Einstein</span>
<h2 property="dc:title">E = mc<sup>2</sup>: The Most Urgent Problem of Our Time</h2>
</div>
</body>
</html>

Notice the two namespace declarations, one for “t” and one for “T”. Both are used to provide properties for the object being described in the document: t:apple and T:banana. Parsing the document with a RDFa application that applies XML rules, treats the namespaces, “t” and “T” as two different namespaces. It has no problem with the RDFa annotation.

However, using the rdfquery JavaScript library, which treats “t” and “T” the same because of HTML case insensitivity, an exception results: Malformed CURIE: No namespace binding for T in CURIE T:banana. Stripping away the RDFa aspects, and focusing on the namespaces, you can see how browsers handle namespace case in an HTML document and in a document served up as XHTML. To make matter more interesting, check out the two pages using Opera 10, Firefox 3.5, and the latest Safari. Opera preserves the case, while both Safari and Firefox lowercase the prefix. Even within the HTML world, the browsers handle namespace case in HTML differently. However, all handle the prefixes the same, and correctly in XHTML. So does the rdfquery JavaScript library, as this test page demonstrates.

Returning to the discussion, there is some back and forth on how to handle case sensitivity issues related to HTML, with suggestions varying as widely as: tossing the RDFa in XHTML spec out and creating a new one; tossing RDFa out in favor of Microdata; creating a best practices document that details the problem and provides appropriate warnings; creating a new RDFa in HTML document (or modifying existing profile document) specifying that all conforming applications must treat prefix names as case insensitive in HTML, (possibly cross-referencing the RDFa in XHTML document, which allows case sensitive prefixes). I am not in favor of the first two options. I do favor the latter two options, though I think the best practices document should strongly recommend using lowercase prefix names, and definitely not using two prefixes that differ only by case. During the discussion, a new conforming RDFa test case was proposed that tests based on case. This has now started its own discussion.

I think the problem of case and namespace prefixes (not to mention xmlns as compared to XMLNS) is very much an edge issue, not a show stopper. However, until a solution is formalized, be aware that xmlns prefix case is handled differently in XHTML and HTML. Since all things are equal, consider using lowercase prefixes, only, when embedding RDFa (or any other namespace-based functionality). In addition, do not use XMLNS. Ever. If not for yourself, do it for the kittens.

Speaking of RDFa in HTML issues, there is now a new RDFa in HTML issues wiki page. Knock yourselves out.

updateA new version of the RDFa in HTML4 profile has been released. It addresses a some of the concerns expressed earlier, including the issue of case and XMLLiteral. Though HTML5 doesn’t support DTDs, as HTML4 does, the conformance rules should still be good for HTML5.

Categories
Web

Cite not link

I do have considerable sympathy for 1Thomas Crampton, when he discovered that all of his stories at the International Herald Tribune have been pulled from the web because of a merger with the New York Times.

So, what did the NY Times do to merge these sites?

They killed the IHT and erased the archives.

1- Every one of the links ever made to IHT stories now points back to the generic NY Times global front page.

2- Even when I go to the NY Times global page, I cannot find my articles. In other words, my entire journalistic career at the IHT – from war zones to SARS wards – has been erased.

At the same, though, I don’t have as much sympathy for Wikipedia losing its links to the same stories, as detailed by 2Crampton in a second posting.

The issue: Wikipedia – one of the highest traffic websites on the Internet – makes reference to a large number of IHT stories, but those links are now all dead. They need to delete them all and find new references or use another solution.

As I wrote in comments at Teleread:

I do have sympathy, I know I would be frustrated if my stories disappeared from the web, but at the same time, there is a certain level of karma about all of this.

How many times have webloggers chortled at the closure of another newspaper? How many times have webloggers gloated about how we will win over Big Media?

The thing is, when Big Media is gone, who will we quote? Who will we link? Where will the underlying credibility for our stories be found?

Isn’t this exactly what webloggers have wanted all along?

Isn’t this what webloggers have wanted, all along?

I have sympathy for a writer losing his work, though I assume he kept copies of his writings. If they can’t be found in hard copies of the newspaper, then I’m assuming the paper is releasing its copyright on the items, and that Mr. Crampton will be able to re-publish these on his own. That’s the agreement I have with O’Reilly: when it no longer actively publishes one of my works, the copyright is returned to me. In addition, with some of the books, we have a mutual agreement that when the book is no longer published, the work will be released to the public domain.

I don’t have sympathy for Wikipedia, though, because the way many citations are made at the site don’t follow Wikipedia’s citation policy. Links are a lazy form of citation. The relevant passage in the publication should be quoted in the Wikipedia article, matched with a citation listing the publication, author, title of the work, and publication—not a quick link to an external site over which Wikipedia has no control.

I’m currently fixing one of my stories, Tyson Valley, a Lone Elk, and the Bomb because the original material was moved, without redirection. But as I fix the article, what I’m doing is making copies of all of the material, for my own reference. Saving the web page is no different than making a photocopy of an article in the days before the web.

In addition, I will be adding a formal citation for the source, as well as the link, so if the article moves again, whoever reads my story will know how to search for the article’s new location. At a minimum, they’ll know where the article was originally found.

I’m also repackaging the public domain writing and images for serving at my site, again with a text citation expressing appreciations to the site that originally published the images.

By using this approach, the stories I consider “timeless”, in whatever context that word means in this ephemeral environment, would not require my constant intervention.

Authors posting to Wikipedia should be doing the same, and this policy should be enforced: provide a direct quote of relevant material (allowed under Fair Use), and provide a formal citation, in addition to the link. Or perhaps, instead of the link. Because when the newspapers disappear, they’ll have no reason to keep the old archives. No reason at all. And then, where will Wikipedia be?

1Crampton, Thomas, “Reporter to NY Times Publisher: You Erased My Career”, thomascrampton.com. May 8, 2009.
2Crampton, Thomas, “Wikipedia Grappling with Deletion of IHT.com”, thomascrampton. May 8, 2009.

Categories
SVG XHTML/HTML

Whipping boy

I noticed a passing twitter message from Laura Scott. It said One word: standards. Firefox follows w3c standards. Internet Explorer does not. She wrote it in response to another Twitter message from tutu4lu, who was having problems with a web page appearing differently with IE than Firefox.

It is true that Firefox implements more standards than IE, especially in when it comes to some of my favorites, such as SVG. And I appreciate the fact.

Firefox does not necessarily get an A+ for all of its effort, though. In particular, if Microsoft’s lack of implementation of XHTML has been one force against broader implementation of XHTML at web sites, Firefox’s own handling of XML errors in XHTML is another, more subtle force against XHTML.

Here’s an example. I added an ampersand (&) to a URL in one of my posts, which generates an XHTML error. The following are three screen shots from Chrome, Opera, and Safari, respectively, that demonstrate how they handle the error:

XHTML error in Chrome
Opera XHTML error
Safari error

Safari and Chrome are both built on WebKit, which handles XHTML errors by parsing, and rendering, the document up to the error. This has the advantage of providing some content, as well as being able to more quickly find the error when you’re debugging.

Opera doesn’t render the document, but it does provide a display of the source with highlighting where the error occurs. This is extremely helpful when you’re debugging a larger document. In addition, Opera also provides an option to render the document in HTML, rather than XHTML, which is helpful for everyone else.

Contrast and compare these screenshots with the following, from Firefox.

Firefox error handling

The Firefox XHTML error handling is also known as YSOD, or Yellow Screen of Death. It’s harsh, abrupt, and somewhat punishing in nature, with its sickly yellow background, and bright red text. The message is typically cut off by the edge of the browser window, so one can’t easily see where the error has occurred. It’s most definitely intimidating for readers who accidentally stumble on to an XHTML page currently in a broken state.

All four of the browsers do support the XHTML standard, and all stop processing the XHTML when an error occurs, as is proper. But where Safari/Webkit, Chrome/Webkit, and Opera try to provide a useful web page, Firefox picks up a ruler and gives the owner of the web site a good whacking.

It’s easy to fall into the trap of blaming all web development and design problems on Microsoft and IE, and to use IE as a whipping boy—to the exclusion of looking, critically, at the other browsers in the web space. If the lack of support for XHTML in IE is a primary inhibitor of the spread of XHTML, Firefox’s YSOD has to take the second place prize. Support for XHTML doesn’t end at the parser.

Categories
Diversity Technology

Open Arms

Regarding the recent Golden Gate Ruby Conference…

Sara Allan

The second low point was Matt Aimonetti’s talk “CouchDB + Ruby: Perform Like a Pr0n Star.” It is unfortunate that he took this joke too far. What might have been a short, juvenille, eye-rolling bit of humor continued throughout the talk to become increasingly disturbing. Amidst this normally warm, welcoming community, I spent an uncomfortable half hour wondering if I had somehow found myself in 1975.

…

If he had left it at a few introductory jokes, I would be writing a very different post. Instead the porn references continued with images of scantily-clad women gratuitously splashed across technical diagrams and intro slides. As he got into code snippets, he inserted interstitial images every few slides (removed from the slides below). The first time it happened, he mentioned that he wanted to keep everyone’s attention. It had the reverse effect. This technique was distracting and disrespectful to an audience who, frankly, is turned on by code.

Audrey Eschright

Here’s another problem in this tangle: Ruby (and Rails in particular) loves the rock star image. You see it in job posts, how people talk about their work, and the way Rubyists rant on their blogs. It’s macho, it can be offputting to both genders, and it makes it easy in this kind of situation to say, “what’s your problem? I’m just busy being awesome”. It’s also a significant barrier to adoption for people who aren’t already a part of this culture, and don’t find it appealing.

Mike Gunderloy

For what it’s worth, I think the original presentation was an inappropriate and regrettable mistake. However, far more disturbing to me are the reactions to the discussion on the part of some of the Rails community.

Folks, the idea that women are disproportionately underrepresented in engineering and software in general, and open source development in particular, should not be new and controversial in 2009 – anyone who cares to look can find such things as the FLOSSpols findings, or any amount of academic literature on the subject. Anyone who cares to take the time to actually talk to the women who are a part of the open source community will have no trouble getting an earful about how challenging it can be to participate.

…

But unfortunately for me, in parallel to the public discussion there have been private ones. I can’t reveal details without breaking confidences, but suffice it to say that a significant number of Rails core contributors – with leadership (if that’s the right word) from DHH – apparently feel that being unwelcoming and “edgy” is not just acceptable, but laudable. The difference between their opinions and mine is so severe that I cannot in good conscience remain a public spokesman for Rails.

Victoria Wang, in comments

DHH’s attitude seems to say that the more we lower ourselves to the most base level of marketing scum in the name of entertainment, the better, even if at the end of the day there are no more women, or anyone worth knowing, in the room. It kind of makes me want to never touch Rails code again.

Rev Dan, in comments

What chaps my ass about the whole thing is that it’s doing little more but reinforce the bullshit “developers are immature, overgrown 14-year-olds” stereotype. I’m sick to death of that one, especially because I run into that type of jackass more often than I care to.

We kinda have a “chicken and egg” scenario going on here… unless there are more women who attend these things then the few women who do will always feel like outsiders… but if the few women who attend now are offended, then why will more attend?

Matt Aimonetti’s response

In the case of my talk, people knew what to expect, they *picked* the talk, and were warned by the organizers before I started that I would be using imagery potentially offensive to some. The topic of my talk was obvious, and I would have hoped that people who were likely to be offended would have simply chosen not to attend my talk or read my slides on the internet. It’s like complaining that television has too much material unsuitable for children, yet not taking steps to limit their viewing of it. You can’t have it both ways.

We can argue forever about morals, professionalism, ethics, respect, etc., though this is all a distraction from the real problem that was raised by Sarah, namely that we have very few minorities in the Ruby community, especially women. Minorities do need to be more represented!

Ryan Bigg

I fear that it will rip a community apart. A community that should be working together on getting past this issue and bettering themselves, not regressing to childish bickering. That’s what gives this community an “immature” stamp by the [insert other programming language here] groups.

…

All I ask for you guys is to…

Chill.

Sho Fukamachi

Other reactions include pathetic “I am being victimised” attention-seeking, lame attempts at demonstrating how much “I truly care about women” etc, hilarious “I am leaving the Ruby community and re-installing Visual Studio” threats (please do!), and every combination thereof. I cannot help but think that if Matt’s presentation has the effect of getting rid of these disingenuous wowsers then he should henceforth be invited, nay required, to present at every Rails conference.

DHH, the father of Rails



But wait…there’s more…

Alpha Male Programmers aren’t keeping Women Out

You certainly have to be mindful when you’re working near the edge of social conventions, but that doesn’t for a second lead me to the conclusion that we should step away from all the edges. Finding exactly where the line goes — and then enjoying the performance from being right on it — requires a few steps over it here and there.

update

Excellent aggregation of opinions from women in the Ruby/Rails community. Particularly liked Amy Hoy’s take in comments

If you are going to try to be edgy and push boundaries and shit, you should at least be sure you’re good at it and know how to handle that kind of content, first. Otherwise, it’s just destructive.