ERH’s comments on XForms, as part of his predictions for 2007. Worth a read. -m

Check it out. -m

Some random thoughts and responses to lots of blog discussion sparked by the XML2 article, where I asked “Is HTML on the Web a special case?”

By which, I mean, if you go through all the effort of writing down all the syntax rules used by the union of browsers that you care about, then go through the pain of getting consensus within a standards body, will the resulting document be useful beyond HTML on the Web, much like how XML is useful beyond being a vehicle for XHTML?

I don’t know if Tim Bray had that same version of the question in mind, but he answers “obviously ‘yes’”.

But I don’t think so. Once you have that set of rules, wouldn’t it be useful in other areas, say, notoriously RSS on the web? SVG? MathML? In fact, I’d go as far as saying that any hand-authored markup would be a candidate for XML2 syntax.

What about mobile? Anne van Kesteren responds:

in that article Micah Dubinko mentions mobile browsers living up to their premise and all that. What he says however, isn’t really true. Mobile browsers and XHTML is tag soup parsing all the way.

He links to this page, which does a rather poor job of making a point the author seems to have decided upon before starting the experiment. If you look at the specific test cases, one tests completely bizarro markup that no author or tool I can imagine would ever produce. Another test checks the handling of content-type, not markup. On the other axis, the choices there seem a bit jumbled: lists of user-agent strings, one for stock Mozilla, and a footnote indicating confusion about what browser is really in use. If anything, this page shows that the browsers tested here, with the exception of Opera Mini, are crap. If you spend more than a few minutes in mobile, you’ll discover this widespread trend. (And I’m working on a solution…watch this space).

Look at this from a pragmatic viewpoint. Check the doctype used on Yahoo! front page vs mobile front page. Despite the poor browsers, XHTML adoption is still farther ahead on the mobile web then the desktop web.

The last thing nagging at me (for now) is whether XML2 will have an infoset. Will it be possible to use XPath, XQuery, and XML tools on XML2 content? How well will these map to each other? In the strict sense, no, XML2 won’t have a conforming infoset because it will never include namespaces. But might it support a subset of the infoset? (Would that be a infosubset?) That’s a huge open question at this point. -m

An easy to use UBL Editor. Has anyone tried it? -m

So, about a year ago, I wanted to use XPath 2.0 on a project. Turns out no non-toy, non-alpha versions existed except in Java land (where Saxon is quite good). Has the situation changed at all? Anything on the horizon? Libxml2? Anybody?? -m

A semi-random thought that occurred to me.

One marker of a well-designed markup language is that it looks to the future. This doesn’t mean it’s an amorphous blob of abstract indirections mapped to tags. It can (and arguably should) be concrete and solid, but designed in such a way that keeps bigger things in mind.

HTML and XHTML are, I suppose, canonical examples of this, giving birth to microformats and many other uses outside of a browser. -m

In case you didn’t notice, a new XML Annoyances is out. From the first comment there:

markup typo
2007-01-11 18:58:33 Michael Dyck [Reply]

In the link following “same unofficial naming scheme as”, the attribute is missing its closing quote-mark, which (in my browser at least) causes a lot of the subsequent text (up to the next quote-mark) to be slurped in as the attribute value, effectively hiding it.
(Indeed, “well-formedness on the Web is dead”.)

This might be fixed by the time you read this, but indeed an interesting typo.

Update: I checked my original submitted article, and indeed there error isn’t there–it found its way in during the production process. But the interesting fact remains that it could happen in the first place 1) without causing any major problems, and 2) causing varied minor problems depending on the browser. -m

And a few not so open…

Q: Does the iPhone (or specifically the desktop-grade Safari browser) make the “mobile web” obsolete?

A: The “mobile web”, as we know it today, will become obsolete without any help. Things change. Devices improve. That said, the context in which one uses the web is different, and there will always be a need for some sites to have mobile-specific versions, even after the day every mobile browser is desktop-grade.

Q: Does the advent of desktop-grade mobile browsers mean that today’s mobile development is meaningless?

A: No. The race is on today, and the winners will be those who can make the most users happy. That includes users who–for several more years–won’t own hardware capable of desktop-grade browsers. The winner on this playing field will have any easy momentum play to carry over to the next one.
Q: Will the iPhone “cannabalize” iPod sales?

A: Goodness, no. People who buy one will be either 1) buying it instead of an iPod, or 2) not. The Cingular CEO said it was a “multi-year exclusive” deal, signed sight unseen. In other words, Apple had incredible leverage to get a good deal. Their subsidy on the 2-year contract is probably significant, maybe in the $300 range, possibly a lot more. So would you call selling a $800-900 device instead of a $200 one cannabalization?

Q: What does this mean for XHTML-MP and XHTML Basic?

A: That’s a tough question. In the end, it will boil down to momentum. Today’s successful mobile development necessarily involves XHTML. Once browsers get better, nobody is going to re-write their sites in worse markup, though some might attempt to merge with the main site. (Another open User Experience Design question is the degree to which it will be possible for one site to work in a different, mobile, context.)

Q: What does this mean for Mobile Web Best Practice and mobileOK?
A: Like the “mobile web” both of these specs-in-progress will become obsolete without help. But now they are going to look increasingly obsolete at an accerated rate.

-m

Here’s a great new project on Sourceforge: XForms for UBL. In my book, I started in on something like this. Here is a more complete, more up-to-date, fleshed out solution. -m

Last week, I visited Erik Wilde, Bob Glushko, and students up at Cal. No major announcements, just some sharpening of discussion points.

Since this was my first visit to Berkeley, I finally got to tell the joke “thank you for your OS”. Maybe you had to be there.

The intentional web is a formalism for describing “why the font tag is evil”. I often work with 3rd party integration languages, and the markup design is, without exception, crap. I hypothesize that the reason for this is jumping into solution-space before fully understanding problem-space. This seems to apply to lots more than just font tags; I lumped in WML and about half the world’s ajax sites for good measure.

Microformats are a formalism for describing “why creating a new markup language for my CD collection” is evil. Could XForms have been done as a microformat? No, microformats require a strong intentional foundation language, and HTML forms ain’t it. Is the proposed W3C approach an instance of “a deadly two-pronged attack”, a la Yahoo! Photos + Flickr? We’ll see. It does seem like that road leads to a namespace apocalypse, highlighting the fundamental difficulty namespaces hoists on attempts to usably extend HTML and XHTML at the same time. A namespace apocalypse may not be a bad thing.

On namespaces, I went over most of the points from my recent article. I won’t rehash that here.

What are some practical and implementation issues around XForms or the lack thereof? Focusing on mobile, as reason #1 I gave the lack of commercial-grade java browsers, discussed here previously. The state of mobile browsers is appalling, other than Opera and S60. Terms like “model” and “field” are troublesome, because the confuse the problem domain (the real world) and the solution domain (the computer). Browser vendors have been too inwardly-focused, both now and during the first attempt at salvaging HTML forms, leading to a premature jump into solution-space. But perhaps XForms dwelled for too long in the problem space…

Maybe I’ve mellowed some, but increasingly I’m able to look at both sides of issues. A useful skill for Information School students, wouldn’t you agree? -m

This Wednesday, I’m visiting Berkeley to speak with visiting professor Erik Wilde and his School of Information students. It’s an open-ended discussion, but will almost certainly center on XForms, the intentional web, and related information flow technologies. If you’re in Berkeley this Wednesday, drop me a line. -m

The new Flickr Mobile site is up, joining the recently-launched m.upcoming.org. Notice a trend in mobile URL design here? Expect to see more of this from Yahoo! and other places.

The interesting thing about these URLs is that they don’t end in .mobi. There are technical advantages (cookies) to staying with an established domain name. What are your plans, if any, for dot-mobi domains? -m

but there has never been a successful Java implementation of a commercial-grade web browser. (right?)

There exist lots of huge applications including IDEs, and editors of all sorts, but nobody’s been able to nail the whole XHTML+CSS+JavaScript thing in Java. (right?)

Take it a step further–no need to pick on Java–nobody has done this in any VM-based language (right)?

Coincidence or sign of greater forces in the universe? Feel free to post counter-examples in the comments.-m

Watch xml.com this week: the XML Annoyances column is returning, and not a moment too soon it seems. -m

Just ran into this. Nice! Mobile mashups are getting some serious momentum.

To elaborate on my previous comments a bit, the concept of what people find usable differs between sitting at a desktop and sitting/standing/running/driving with mobile in hand. Desktop sites aren’t optimized for these kinds of use patterns. Ergo, fertile ground for lots of mashups. You were getting tired of the Maps API + X formula anyway, right? ;-) -m

Whoops, the feedback email address for the XForms Validator was down after my last round of changes. Fixed. -m

All right, the article is actually 12 Lessons for Those Afraid of CSS and Standards, but if I were to write the same list for mobile development, it would be almost identical. -m

Article (with a non-best-practice URL) from seomoz. If you’re into this kind of thing, Web 2.0 The Book has an entire chapter on it. Nitpick: Also note how normal folks say URL, not the even-more-geeky URI. -m

Another example of a small, useful spec defined in a language humans can actually read and understand. It also seems incredibly useful to be able to print basic things without going through the multi-megabyte printer driver madness that everyone else seems to be going for. -m

I got this link from Eve, and to think, I never even knew there was a consortiuminfo.org. The Microsoft Open Specifications Promise irrevocably lets any interested parties implement and use a list of technologies without fear of getting sued (at least sued by Microsoft). It is similar in tone and scope to earlier declarations about the Office XML formats, and the declaration from Sun about UBL. I’m not a lawyer, so if I’ve described this badly, get a real lawyer to explain it. :-P
This is a smart move; since obviously a great deal of work went into producing these standards, I’m sure Microsoft plans to benefit more by growing the “whole market” (in the language of _Crossing the Chasm_) then they would by nickle-and-dime asserting patent rights. They also come out far, far better in public opinion, especially among those most affected by these standards.
There’s another angle worth considering–the defensive. Giving away patent rights carte blanche might at first seem like a funny kind of defense, but here’s how it works: after today, what would happen if BigWebServicesCo started shaking down implementers of WS-Whatever? The attacker would be savagely torn apart in the court of public opinion, that’s what. Submarine patents are dirty business, so for a bigger target, creating an environment more hostile to such bad behavior is a powerful strategy.

Of course, smallish parasitic patent troll companies won’t be deterred much, but then again nothing seems to.

I’m optimistic that this is part of a positive trend. I’ll even refrain from further opinions on the WS-* technologies. :-) -m

A must-read posting from Mark Birbeck, who knows a few things about XForms and Web Forms 2.0.

He talks about the respective approaches embodied in XForms and Web Forms 2.0, and concludes that the primary difference between them has little to do with simplicity. He goes on to analyze differences in how developers and users view browsers. Go read it, it’s worth it. -m

I’ve written before about the xslt2xforms project by Sébastien Cramatte. The project is not only still alive, but expanded into an entire utility kit including a PHP5 framework and forming “a complete xforms/xml toolbox based only on w3c standards”. Check it out on sourceforge. -m

Check out this script. -m

Like with the element counts, the grain-of-salt alarms are going off with this one. But apparently IE7 passes only 54% of the CSS test suite, up from 52% for IE6. (But even Mozilla only scores 93%). It’s not entirely clear how these numbers derive from the source data, and it certainly isn’t weighted for things like how useful or commonly used various features are.
It’s completely silly to say Microsoft isn’t even trying to implement the standard. Every engineer, product manager, or blogger involved with the project will honestly and sincerely describe the huge amount of effort going into standards compliance. To get to the problem, you need to dig deeper.
I’ll end on that enigmatic note. More later. -m

First off, counting the number of elements isn’t a useful metric for serious discussion  about vocabularies–but it is fun. :)  Eric van der Vlist reports on the latest XHTML and related specs. -m

Yes, the devastating two-pronged attack is in full swing. Link. -m

Word on the street is that some of the new stuff in XForms 1.1 is fantastic. Also on my to-carefully-read list, the mobileOK Scheme. As always, any thoughts welcome here. -m

Write up by Duncan Cragg. More and more momentum is building for this meme. -m

Hey readers, help me guide my scattered thought processes.
I’ve been thinking lately about microformats, which are typically characterized by inline annotation through existing class attributes in XHTML. You put the rel=”self” or whatever right into the document, on the element you’re talking about.
Another approach, that used by CSS itself, is to keep all the extra information bunched together in a different place. There’s all kinds of phrases, usually beginning with “separation of” to describe this pattern. And to do so requires a specific way to connect the external information, typcially called a binding. For CSS, it’s Selectors.
OK, so far so good. Except that it’s possible, and common in some cases, to have style attributes, taking CSS in the inline annotation direction. The lines are blurrier than they might seem at first.

So, Yahoo! has started publicly supporting microformats, which is great, because they are the ones generating the pages. What if you want to make a microformat out of 3rd party XHTML without touching it?
Here’s my questions. Feel free to comment below. I’m travelling, but I’ll try to moderate asap.

1. In the specific case of CSS, how do you decide inline vs. binding?
2. Are any microformat efforts currently looking at a binding approach vs. inline annotation? Which ones?
3. What general principles should readers keep in mind for this discussion?

Thanks! -m

Yeah, help still wanted. I’m looking for a markup and standards guru to work with me on a cool Mobile project. Can you list five different types of CSS selector off the top of your head? Can you map all five to the equivalent XPath? Can you spot semantic markup by reflex? Do you daydream about microformats or scribble down BNF during idle moments? Do you obsessively check the TR page at the W3C?

If you answered YES to the above questions, send me your CV. Include “Yahoo!” somewhere in the subject line. -m