Push Button Paradise

Rebirth in PIM space

Looks like I spoke too soon. On April 24, Chandler will be unveiled.
Waiting impatiently. -m

2 New Linux distros find their home

There's the Zaurus, running kernel 2.4.6, and also the excellent Mandrake 9.1. Now, back to work on the book. -m

Pay attention to BPM

Business Process Management goes mainstream
-m

Slowdown in PIM space?

Traffic on the OSA foundation design mailing list for the Chandler project has slowed down to a crawl. Only one message in today's digest version. And Mitch's weblog hasn't been updated since Feb 2, and Rys's since Feb 16. But it's not just the excellent OSAF guys.

Similarly, the Zoot Forum has slowed down to a trickle--just four messages in five days.

-m

The connection between Documents, Forms, and XML

In a prescient article from March 15, 1999 (which I have had printed and hanging in my office since then), David Weinberger writes:

"Just as television diminished theatre, and cars diminished the scenery through which we drive, XML � certainly an important innovation � will diminish an important part of our current experience: writing documents. Instead, we'll be filling in more and more forms."

Exactly right. Give the average "information worker" a paper form, and they'll write illegibly, scribble in the margins, doodle, write in new choices, and just generally do things that aren't expected--and are manually intensive to cram into a database.

Throw in XML with a strict DTD or schema, and you can guarantee ready-to-go data. Just watch out for frustrated users when your beautiful multiple-choice selection list is missing the one choice that the user needs.

Why mention this now? I'm writing in my book a section called "More than forms".

"Forms are the way we constrain writers. XML lets organizations benefit from structured, predictable documents. Thus, XML breeds forms. QED."

-m

eWeek writes:

Mozilla 1.3 also includes a demonstration of a capability, code-named Midas, that will be supported in future versions of the browser. Midas lets Web developers add rich-text editable controls to pages using standard script commands. We found this feature interesting but were not sure why it was included--there are already standards-based ways to do basically the same thing across all browsers.

Does anyone have any idea what the "standards-based ways" to "already" do rich text are??

-m

Quotage on xml.com

You heard it here first. :-)

-m

HELP WANTED:

If anyone has instructions on how to disassemble (and hopefully later reassemble) a troublesome HP Pavilion XH-series notebook, please send me a note. I already have the heat-sink fan assembly to replace the one making the sound that's between cats in heat and an electric drill. Anyone?

-m

P.S. The back of the assembly, of what looks like the CPU heat sink, says "TORQUE 15 +/- 0.5 Kg-cm". Where can I find the tool for this?

Making XML Easier

Tim Bray writes that XML is too hard for programmers. He references Adam Bosworth, who is complaining that code like this doesn't work for XML:

XML x  = getxml("somewhere");
PERatio = x.price/( x.revenues - x.expenses);

Instead, complicated navigation with DOM or XPath is needed, or complex state tracking with SAX.

Now, look at what's really going on in that sample: 'price', 'revenues', and 'expenses' are all unique values that can't be duplicated. In other words, they're IDs.

Anyone who's worked much with XML knows that IDs are painful, since they require DTD or schema processing. A recurring proposal has been circulating for a self-describing xml:id attribute that confers ID-ness without need of DTD or schema. With that in place, even XML delivered inside the DTD-free zone of a SOAP envelope could be handled with code not significantly more complex than Adam's example, and without the dependencies and hassle of a schema language.

This isn't the only thing that could make XML more pleasant (there is, for example, Tom Bradford's Clean Namespaces proposal), but definately in the top 15. -m

Sjoerd Visscher wrote to say that he's provided an RSS feed of this blog. Thanks!

-m

XForms support in XMetaL?

According to this review, the latest version of Corel XMetaL has "the ability to build forms with the emerging XForms standard.". Anyone have experience with this?

The friendly folks at XML 2002 promised me a copy. Time to follow up...

UPDATE: John Turnbull, Senior Program Manager at Corel, just wrote to say that the builder.com is in error. What's supported is the "XMetaL Forms Tookit". Oh well, hope remains. :-)

-m

I missed this while I was at the W3C plenary meeting: Bob DuCharme's xml.com article on multi-ended links, which starts off with a nice reference to SkunkLink.

-m

Mark Baker thinks that InfoPath is crying out to be a browser-based application. Good call.

-m

xml-edit

On the X-Smiles mailing list, a proposal for a new processing instruction, parallel to xml-stylesheet. Placed on any XML instance data, it would hold a link back to another XML document (presumably XForms) that can be used to perform various edit operations.

Example, using an XHTML+XForms media type:

<?xml-edit type="application/xhtml+xml" title="Content editor"
href="./content_edit.xhtml" alternate="yes"?>


I'd like to see other XForms implementations converge on this technique.
-m

News.com: "Will firms balk at Microsoft's program?"

"This is not a product an end user can use right out of the box," said Gartner analyst Michael Silver. "There is a lot of programming and infrastructure (that) enterprises will have to put in place before they can use it."

Sounds like a case for separating the design-time environment from the entry-time environment.

-m

Has anyone else noticed an off-by-one problem in how blogger stores permalink/archive items?

Might be time to start building my own tools.

-m

Jon Udell: InfoPath and XForms

Jon shares some quotes on the relationship between InfoPath and XForms. I still think there's a somewhat different relationship than what Jon writes about.

I had said:

The difference between a blank form and a filled out form should be minimal, and representable as an XML document.

To which Jon responds:

That seems rather different from InfoPath's radical separation of data from multiple views, which in turn mandates a heavy reliance on XSLT

At which point I get confused. Representing gathered data as XML is an extremely XForms-ish thing to do. And, in fact, there's nothing strictly forms-related about it.

That InfoPath emphasizes multiple views and XSLT is a side issue. (XForms implementations can easily do this too). The benefit comes from having the same XML data representation regardless of the view. The benefit comes from interoperability.

In summary, I'm having trouble seeing useful differences between InfoPath and XForms. Anyone else?

-m

W3C Technical Plenary day

On this slide, XForms has an interesting location, as a foundation, not a narrow application.

-m

P.S. Tantek is live blogging the meeting.

Something I need to check out: http://www.bitfluxeditor.org/
-m

XForms Implementation Workshop

The workshop, held in Boston, is finished. There will be some public minutes later, but for now, I can safely say:

• There are over 20 substantial implementations


• If you've been monitoring the implementation list, there are some surprises in store.


• Attendees came from six countries.

Stay tuned. -m