A lightning talk at the tech plenary is about 3 minutes long and introduces something very specific to the W3C.
I gave a lightning talk on the effecs of adding or changing the stuff in a namespace. You can see the diagram and notes here: http://www.w3.org/2006/03/01-Boyer-Lightning/SignaturesAndNamespaces_Boyer.html
Basically, got a lot of nods all the way up to TimBL himself when I said you either have to use a new namespace, or you have to internally version the language so that old processors for a vocabulary don't try to render new documents with graceful degradation of unrecognized content when the documents have been signed.
Too bad this is exactly what happened with xml:id. It got added to the XML namespace rather than some other namespace, and the version of XML didn't change. Lo' and behold, it broke something. When doing a C14N of a document subset containing orphaned nodes, C14N copies XML namespaced attributes into orphaned nodes when they don't contain their own settings for the nodes.
This is good for xml:space, xml:lang and xml:base, but it isn't good for xml:id.
Truth be told, it's kind of an edge case. In XFDL, we don't even allow you to orphan nodes when signature filtering because the structure of the language is such that an orphaned node is useless without its ancestral chain.
Still, while the problem doesn't affect Workplace Forms, we (in W3C capacity) will still endeavor to fix the problem.
Since the ship has already saled on what namespace xml:id lives in, we're going to be doing a new C14N algorithm that doesn't do the inheritance behavior on xml:id OR one that doesn't do the inheritance behavior except for lang, space and base.
Actually, it's a little more complicated than that, since either of the above choices means that C14N will again be broken in the future when either a non-heritable or a heritable attribute, respectively, is added to the XML namespace.
I think we may have to add a parameterization to the new C14N that allows the author to specify the heritable attributes. This will allow document authors to keep up with adjustments to the XML namespace.
The core WG feels that further additions to the XML namespace are highly unlikely, but I'm not convinced. Just at this tech plenary alone, I heard calls for xml:role (like HTML's role) and xml:profile (like DOM's hasFeature, it would declare that a document has a feature so the processor needs to have the feature or the document won't work). In the past, I've heard a need for xml:src (like HTML src, except HTML's default is wrong-- content should override the attribute rather than the reverse). And my personal fave would be xml:compute to express that the content of an element is computationally derived from other content. The list really does go on once you start to think about XML as an intelligent object...
Smarter Everyone, Smarter Everything, Smarter Everywhere
John M. Boyer 060000VMNY 1,390 Views
John M. Boyer 060000VMNY 1,772 Views
Well, it's only two days into the W3C Tech Plenary and already I have enough things to write about that I cannot possibly inflict it all upon you in one blog entry. So, I'm just going to give an overview so that I'll remember to talk about some of this stuff in more detail later.
But first, an excellent bit of humour from another long-time W3C member who also happens to live in Canada (a little knowledge of Canadian geography and politics helps with this one):
Liam: Where do you live?
John: I live in Victoria, which is near Vancouver.
Liam: Oh, I live in Ontario, which is near Toronto.
Well, it was funny when Liam said it :-)
Anyway, for the first two days here I have been able to sit as observer on other working groups as well as have some individual discussions of some importance. Here is a summary:
The chat with Liam also included his hopes for XForms eventually adopting XPath 2.0. More about this in another blog entry...
Sat in for a while on the Compound Document Formats working group. Major topic of discussion was event flow between DOMs. How do a parent and child document come to agreement on whether events flow between them? Where does the capture phase start? More to come...
Sat in on the XHTML working group. Major topic: XML events. Specifically, how to upgrade XML events to offfer authors the ability to dynamically add and delete listeners after the document is first loaded. There's not a lot of complexity semantically, but the discussion of the vocabulary involved led to a very exciting discussion about the meaning of namespaces, especially as applied to attributes. This will be a beaut of a blog entry...
Talked with Doug Schepers, who was very interested in having a declarative way of doing AJAX-like things so that the functionality could be securely enabled even with scripting off. I told him I would demo it tomorrow in my part of the Rich Web Application Backplane panel. It's called XForms. More to come...
Finally, had a very good chat with Jose Kahan and Thomas Roessler about making progress on correcting the impedance mismatch between canonicalization and xml:id, with implications for a revision of XML Signatures. Lots more to come...
Stay tuned for more on these points!
John M. Boyer 060000VMNY 1,725 Views
Very soon, I'll be heading off to the W3C Technical Plenary.
Sure, it's in Cannes, but it's also in February, so it's all business.
This is a time when many W3C working groups congregate in order to have time to have intergroup meeting times. So, the XForms working group will have its face-to-face meeting later in the week, but so will a dozen or more other groups. Similarly, the compound document format group chaired by Kevin Kelly will meet earlier in the week. I plan to sit in on some of that as an observer and to talk as needed about the intersection of XForms and compound document formats.
The mid-day of the plenary is a time for common presentations, one of which is a panel presentation called "Rich Web Application Backplane". Kevin is the chair of the panel, which has a number of panelists including yours truly.
The panel is basically about the notion that we have lots of rich XML processing capabilities available now, expressed as XML. This allows for compound documents that are capable of aggregating the data, views, rich user experience, and web services needed to complete a sophisticated web application transaction.
While some further work can be done to do a better job of creating more seamless integration of various components in the W3C stack, a lot of the foundational technologies are already there and in pretty good shape, so herewith is the rallying call to pull them together into an XML backplane capable of supporting the design of rich web applications.
One of the things I really like is the potential for XML events to be the glue that binds together nicely modularized XML technologies into an effective, intelligent compound document. I think an update to XML events would be useful to add certain key features, but even as-is the capture and bubble phases combined with event context have allowed me to express an integration of XML signatures into a compound document format that includes XForms and a first class presentation language (XFDL, of course).
Of course, whenever we talk about advancing the conceptual model of the web in some way, we get a certain amount of feedback about whether we are talking about evolutionary change or revolutionary change. The latter causes IT folks ot go weak in the knees over deployment issues, so branding something revolutionary is really about trying to stop it from happening.
This means that you can have a staged migration to a rich native client that directly runs the high level language because the conceptual model expressed by the language can be delivered, with few limitations, to today's client platforms-- zero footprint.
In the IBM Workplace Forms space, we call the native client "Viewer" and we call the zero-footprint version "WebForm Server". The idea is that you design an XFDL form containing precision presentation, rich user experience and business logic/dynamic interactive capabilities using XForms within the XFDL. Then, you deliver it using one of these two interactive rendition engines.
A demo of this capability is how my panel segment will end. After all, nothing trumps being able to show some of the kinds of capabilities that would be enabled by the rich web application architecture.
I did a customer site visit out in Washingto DC earlier this week (I live on the west coast of Canada). On the plane next to me there was a guy who had a book to read with a title that was something like "Three men, a raft and the most dangerous river". It appeared to be about three guys who navigated the Amazon in a raft.
Perhaps it was just my mood at the time, but it struck me as a little ironic to read a book about it. It's just so much the kind of thing you have to do.
Well, while we're in the land of giant leaps... forms applications are like that too. You can read, but you have to *do* too.
For my own case, the Workplace Forms beta download is accompanied by a reasonably substantial sample form that I wrote to help illustrate for you a number of the important features that are available, such as a wizard-like or guided-interview modality attached to the front end of a "traditional" form.
The internal markup is highly commented and laid out so that you can really get an understanding at the pointy bracket level even if you only have a text editor for exploration (though the beta also includes our eclipse-based designer product).
So, speaking of doing (and also to fulfill my promise to talk about the nitty gritty), it seemed a good idea to share with you one of the interesting things I learned from this form.
The typical form is designed to be used in a particular business context. In general, you will not find that a form (of the size and scope that Workplace Forms targets) is easily purposed to serve multiple locales or business contexts. The "mortgage preapproval" sample form was created to give people in many locales some idea of what the product set can do, but it's not really the intent to address all locale-specific peculiarities. For example, a more realistic form in Russian would have the formulae and inputs adjusted to collect monthly salary information rather than yearly information. And in some locales, it isn't even appropriate to collect interest on a loan, nor is it appropriate to accept a service like a loan for free, so interest is something that is informally negotiated rather than being driven by an exact compound interest formula.
Anyway, as I said we just wanted to provide a form that would give a good idea, so we ended up with the task of translating the form to many languages.
Something I didn't expect happened because I put some localizable strings into certain XML attributes, like an XForms calculate or the value attribute of an xforms:setvalue. The word "Electricity" becomes "L'Electricitie" (pardon my omission of accented characters).
The addition of the apostrophe is problematic when in an attribute because the attribute contains an XPath expression. So you have double quotes around the attribute value, so that single quotes are used around the literal value, and the apostrophe conflicts with that. Moreover, the apos character entity is of no help because that is an encoding consumed by the XML parser, not the XPath parser, so it is converted from a character entity to the literal character by the XML parser so that the XPath parser still receives the offending character.
So, it seems forms have to be designed so that strings intended for humans don't appear in XML attributes that contain XPath expressions. My apologies to my European friends, who no doubt know this already. As I said, pardon my French.
John M. Boyer 060000VMNY 1,604 Views
Got a request today to provide more specific information on exactly where to find the XFDL reference manual.
The documentation site link in my prior post includes a link to the currently released XFDL Reference Manual. For ease of use, the following appears to be the specific link on that documentation site:
Note that you will ultimately receive the XFDL reference manual in PDF; we always publish our language manual in PDF because PDF is good at static readonly documents. XFDL is good at dynamic interactive precision forms applications, but that doesn't mean the language manual should be expressed in it.
On a separate note, you can find a fairly comprehensive technical introduction to the integration between XFDL and XForms in my XML 2005 conference paper. The upcoming version of IBM(R) Workplace Forms(tm) will be accompanied by an updated reference manual that describes the union of XFDL and XForms exhaustively, but at 36 pages, the conference paper actually gives quite a thorough start to those interested in the pointy brackets. Here's the link: