The W3C Forms Working Group has published the First Public Working Draft of XForms for HTML.
XForms for HTML provides a set of attributes and script methods that can be used by the tags or elements of an HTML or XHTML web page to simplify the integration of data-intensive interactive processing capabilities from XForms. The semantics of the attributes are mapped to the rich XForms model-view-controller-connector architecture, thereby allowing web application authors a smoother, selective migration path to the higher-order behaviors available from the full element markup available in modules of XForms.
By separating syntactic form from semantic function of XForms, we now have a linguistic plan for providing the XForms processing model to web authors in a way that is initially more consumable to them and also applicable to their non-XML web pages. And, of course, work has already begun to provide this capability across web browsers via the Ubiquity XForms processor.[Read More]
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...
Forms exist to collect data from web users involved in business processes. Are you a business partner who wants to build solutions more quickly in order to make a higher margin? Then read on!
What if you could use a web browser to design not only the user interfaces of the multiple pages of a form, but also the whole solution for which it collects data?
Now, with IBM Forms Experience Builder, you finally can.
You can define the roles of users in the business process, and you can assign users and groups to those roles. You can even set up open roles whose users are defined dynamically during the business process once the right information is collected earlier in the process. For example, only once you take in a person's name can you access an LDAP service to look up his manager and then assign that person to the manager role for an approval step.
You can define the user interface of a Form, and have an automatic database created on the server side to store database records corresponding to completed instances of that Form. You can even define multiple Forms that work together within a solution that collects data according to different record schemas.
You can define the stages of a business process workflow that uses the Form or Forms to create and update database records. Stage transitions can branch forward, backward or even stay on the same stage to update a database record that still needs more work.
You can define access control for each workflow stage and determine which Forms, page, and UI elements are available in each stage.
You can even use the database records collected with one Form as a GUI configurable web service within the fill experience of a second Form. For example, you could have one Form of a solution that collects inventory data, and then use that data in a second Form that makes it possible to order from available inventory.
You can make the Form fill experience available within a portlet of an IBM Websphere Portal website.
You can create a solution with your web browser, you can save it to the server, you can hit Deploy in your web browser, and then your users can access the Forms of the solution from web links. If you later decide it is necessarily to add to or change the solution, you can edit the solution again using your web browser and hit Deploy again The data is retained for all the remaining form UI elements, and the database tables are altered as needed to make space to store data collected by any new form UI elements.
Via web links, users can access the list of database records collected by the solution. Only the records to which the user has access are presented. If you're the solution creator/administrator, you can get access to all the records. Whomever is given a link to view the records can also set up their own customized filters for the data, so a user can truly use the view as a business process task list, and even filter down to tasks of a particular type, from a particular person, having met or exceeded some value, etc.
Complete agile web solution creation.
Lose the custom coding, gain the market advantage, get IBM Forms Experience Builder now.
There's a new movie due out soon with a really cool name (Snakes on a Plane) and starring an actor I like, Samuel Jackson. Josh Friedman was supposed to help edit the screenplay, but he walked when studio execs threatened to change the name to something banal. However, Sam apparently signed up for the movie because of the name, so it had to stay. Anyway, Josh blogged about months ago, and since then the movie itself has taken on this kind of Web 2.0 existence where the people's conjectures about the movie's content have actually caused the studios to adapt the movie!
Aside from changing the actual film content, the fan base (surreal as that sounds) have actually been responsible for creating marketing hype, movie paraphernalia and even an internet meme for the title. Apparently, Snakes on a Plane is now synonymous "That's Life!" or my personal favorite way of saying the same ("Shh! It happens.") An example from everyday life might be
Programmer on Friday afternoon: "I was going to be done by code module today, but such-and-such didn't properly implement the standard, so now I have to work around their bug."
Hip Manager: "Snakes on a plane. What time did you say you'd be in tomorrow?"
Neat but what's this got to do with Workplace Forms, you say. Well, it's really good to know background cultural information no matter what. Background information is always good to have around. Take for example, an exciting new extension I've recently heard that someone has built for the Workplace Forms Designer. It allows a form author to select a group of form controls, it then figures out the associated markup, and allows the form author to indicate how many times to iterate that markup. Makes creating tables a snap!
Snakes on a plane! Here we are talking about all the cool new features that will be coming in the future of XForms, and the background cultural information that clearly needs further socialization is that
- Workplace Forms includes XForms
- XForms contains a repeat element
- It repeats a given set of controls according to any limits. You could have any number of rows of controls needed to fit your data, though for speed and ease of use we usually recommend keeping a table within a page.
- The design experience is that you just write the table template. No design time duplication of markup.
That last point is really important. Suppose you have some popup selection control that you need duplicated 15 times. Then you decide it needs to have another selection. If you use an XForms repeat, you only have to change the one selection control in the repeat template. If you duplicated controls at design time, then you would have 15 changes to make.
But, hey, at least when the customer asks how to write more maintainable tables, we already have an answer.
As with any computing problem, the issue of performance arises. Here are a few tips that help increase the performance of forms regardless of the version of product being used.
The overarching theme is to know about and use the features of XForms when they are appropriate rather than using XFDL host language features to do the same things. The purpose of XFDL features is to add value to XForms as a host language, but sometimes those features are being used to do the same things as features in XForms. This is less efficient because XForms operates with XPath on the underlying raw data whereas XFDL operates on the formatted presentation layer. Specifically,
- If there is a data value that must be calculated, use an XForms bind with a calculate attribute rather than using an XFDL compute on a value option.
- If a piece of data is required, use an XForms bind with a required attribute rather than an XFDL format option with a mandatory setting
- If a piece of data must satisfy a constraint, such as being greater than another value or within a range, then use an XForms bind with a constraint attribute rather than using an XFDL format option with a constraint setting
- If a piece of data is known to be of a numeric type like integer, use an XForms bind with a type attribute rather than an XFDL format with a datatype. The XFDL format datatype is best for indicating currency and perhaps a date picker (for now).
- If you find that you don't want to show some controls to a user because they are not applicable, such as not collecting data associated with a senior citizen if the person gives an age less than 65, then use an XForms bind with a relevant attribute or use an XForms switch with a state attribute rather than an XFDL compute on a visible option.
Basically, operating on the XFDL presentation layer is slower for two reasons. First, the presentation layer data has to pass through internationalization/localization filters. Second, the presentation layer often has more than one user interface control bound to the same data, so the logic would have to be repeated if expressed at the wrong layer. Overall, I'd have to say that the biggest performance enhancement from the above has been observed by people who used an XForms bind with a constraint rather than an XFDL format constraint. Generally, XFDL formats are expensive, and the XForms repeat has made it easier to create lots of them, so use XFDL formats sparingly within XForms repeats (i.e. within XFDL tables).
Lotus Forms has supported XForms for a number of years now, and you can get a good idea of all the features supported from the XFDL reference manual.
However, now that XForms 1.1 has been finalized, I've had a number of questions about shining a spotlight on the XForms 1.1 specific features in Lotus Forms. Quite a number of XForms 1.1 features were improvements to the semantics of pre-existing XForms 1.0 features, and no small number of those improvements were based on feedback from the IBM Victoria Software Lab, so obviously we implement those and it would be too long to go into them. The spotlight will be on Lotus Forms features syntactically activated with new XForms 1.1 vocabulary that was not available in XForms 1.0.
One of the coolest and most powerful additions to XForms 1.1 were the if and while attributes on XForms actions. XForms actions are behaviors like changing data values, insert or deleting nodes, or making web service calls, and they can be set to happen in response to events like a button press (DOMActivate) or user input (xforms-value-changed). The if and while attributes enable XForms actions to be conditionally or iteratively executed when these events occur.
Lotus Forms supports the context and origin attributes on insert and delete actions. These attributes enable handling of empty repeating data, and they allow repeating data to be copied from a data template. It is much easier to handle dynamic table data with these features. Also, when deleting a data node representing a row of a table, if the table becomes empty, then the above if attribute can be used on an insert to detect that this has happened, and insert a new empty data node. The net result observed by the user is that deleting the last row of a table looks like it just clears out that row so that the user can start immediately entering more data.
Lotus Forms also implements the XPath function compare(), which means a form author could use XForms actions with the if and while attributes to sort or search data, if the need arose. Several other functions are implemented, including:
random() - in case you want to write a Lotus Form that plays Black Jack
current() - to help with data table lookups
power() - for exponential calculations such as compounded interest payments
days-to-date() - can be used in combination with days-from-date() to do simple date math like "today plus 90 days"
seconds-to-dateTime() - can be used in combination with seconds-from-dateTime() to do dateTime math like "now plus 3 hours"
local-date() - provides the date for the end-user, rather than the UTC date
local-dateTime() - provides the end-user date and time, rather then the UTC date and time.
Lotus Forms supports the display of images
obtained from XForms instance data, in both button and label items, using the mediatype="image/*"
attribute setting on xforms:output
Lotus Forms supports the xforms:* datatypes, which allow an empty string to be valid on the corresponding xsd:* datatypes, like xsd:date. Whereas pure XML schema datatype definitions are intended to define what constitutes valid completed data, this feature of XForms recognizes the importance of a good user experience before and during completion of the form.
Finally, Lotus Forms supports several of the new features of xforms:submission, including:
- the method="put" and method="delete" attribute settings to round out access to ATOM publishing services
- the relevant and validate attributes, which allows a submission to turn off data validation and relevance pruning. This can be used to implement a "Save to Server" capability so that a user can perform a fill experience over multiple sessions.
- the serialization="none" attribute setting to enable an xforms:submission to perform simple URL activation.
- The targetref attribute, which enables a web service call to replace only a portion or subtree of a data instance.
- The replace="text" attribute setting, which allows a web service call to replace the content of the target data node, rather than the data node itself. This is useful for accessing web services that return textual content rather than XML.
Lotus Forms also has a number of XFDL extensions that add value to the integration with XForms, but that is the subject of another blog for another time.
We're just finishing up the XForms face-to-face meeting in Amsterdam. Given my prior post and the approach of XForms 1.1 toward last call status, it seemed a good idea to talk about the improvements to XForms 1.1 that make the repeat construct easier to work with.
It's about being able to say more exactly what you mean, really. For example, on my first night in Amsterdam, my hotel room became quite cool, but it wasn't clear how to turn up the heat. Apparently I'm just not old school enough to relate to a radiator, so I called down to the front desk. I was informed that in order to turn the heat up in my room I had to "squeeze the knob". On the radiator was implied. Despite being pretty good with a pun, it seems I still needed a friend to help me fully appreciate how important my complaint about the advice truly was, especially in Amsterdam. In fine propeller head form, I complained that the proper advice was to "turn" the knob. On the radiator was again implied. Oblivious to any possible alternate interpretations, I proceeded through the explanation that while squeezing the knob was a necessary component of turning it, it was also an implicit part of the process which created the friction necessary to ultimately turn up the heat. From the radiator was implied.
Anyway, the point is that a lot of trouble can be avoided when one is able to say exactly what one means to say. In the case of XForms 1.1 authors, there are two new attributes on the insert action that make it a lot easier to manage repeat constructs. In XForms 1.0, we add to the container element of a sequence an extra subelement to act as the prototypical data. We must add the prototype as a child of the container element because the insert action in XForms 1.0 can only get the prototype from the last node of the sequence of items over which it operates. This limitation forces you to adjust the repeat to omit the last node, and it forces you to add application logic to remove the last node when the data is submitted or alternatively before it is processed on the server side.
In XForms 1.1, there is a new origin attribute on the insert action. This attribute allows you to give an XPath that says where the prototype for insertion is located. This allows it to be placed in another instance rather than being stored in the container element of the sequence, which eliminates the necessity of adjusting the repeat and of removing the prototype later (it's already in a separate instance).
The second issue that we solved in XForms 1.0 by putting the prototype data at the end of the container element is that we avoided the problem of the container element becoming empty. It is easy to understand the need for an empty shopping cart, but if the data container becomes empty, then the insert nodeset attribute produces empty nodeset, so you don't know where to insert the copy of the prototype node. To be clear, if nodeset="/cart/item" returns empty nodeset, it's like walking off a cliff because you don't know that the XPath expression visited the cart element right before it found zero elements named item within it. In order to insert into an empty repeat, the parent of the elements being repeated must be non-empty in XForms 1.0.
In XForms 1.1, we solved this by adding a context attribute to insert. The context attribute set the context for evaluating the nodeset attribute. The expected use of this attribute is to choose the parent or container element of the nodeset. So, when the nodeset resolves to empty nodeset, the context node is used as the container item into which the prototype node is inserted. So here's the shopping cart example in XForms 1.1.
<!-- Initial instance data contains the prototypical node as the last element -->
<xf:instance id="liveData" xmlns=""> <cart> </cart></xf:instance>
<xf:instance id="protoCart" xmlns=""> <cart> <item> <name/> ... </cart></xf:instance>...
<!-- repeat operates over the live data -->
<xf:repeat nodeset="item" id="repeatCart"> ...</xf:repeat>
<!-- Add new row after any current row, but do it in a way that can also handle zero rows. -->
<xf:trigger> <xf:label>Insert <xf:insert ev:event="DOMActivate" context="/cart" nodeset="item" at="index('repeat-cart')" position="after" origin="instance('protoCart')/item"/></xf:trigger>
<!-- Delete a row from the repeat. -->
<xf:trigger> <xf:label>Delete <xf:delete ev:event="DOMActivate" context="/cart" nodeset="item" at="index('repeat-cart')"/></xf:trigger>
To complete the example from XForms 1.0 in XForms 1.1, we should now look at an example in which you want a repeat that stays at one row. If the user hits delete for that row, then the row stays, but the data is cleared from it.
<xf:trigger> <xf:label>Delete <xf:action ev:event="DOMActivate"> <xf:delete context="/cart" nodeset="item" at="index('repeat-cart')"/> <xf:insert context="/cart" origin="instance('protoCart')/item" if="not(item)"/> </xf:action></xf:trigger>
In the final insert, we see the appearance of the new if attribute to more precisely communicate that the action is conditionally run. In XForms 1.0, you have to use an XPath predicate to produce an empty nodeset, which is a bit like saying "squeeze the knob". It gets the job done, but it ain't pretty.
The final insert also shows off one of the new things decided at this face to face meeting of the XForms team. In the latest working draft, the nodeset binding is listed as required, but we are changing that to optional in order to make writing inserts like the final one above look more natural. It just identifies the container element as the destination of the insert, the origin as the source of the insert, and a condition that says when to do the insert. And now my room is too hot!
It was a great year for XForms at XML 2007. There were quite a number of presentations that featured XForms as a component, though in this blog I want to focus on the big event for XForms, which of course was the "XForms Everywhere" special session held on Monday evening.
It is no exaggeration to say it was an unqualified success. This was a 2-hour event consisting of six 15 minute presentations by some of the XForms community leaders, including Mark Birbeck, John Boyer (yours truly), Erik Bruchez, Dan McCreary, Keith Wells, and Charles Wiecha. This was followed by a 30 minute keynote from Elliotte Rusty Harold on "How XForms can Win". You can find program details here.
Naturally, we were a bit concerned that the evening slot (7:30-9:30) would test the stamina of the even most eager conference-goers, but the room was filled to capacity (about 60 chairs) and then there wasn't even standing room due to about 20 people standing or sitting at the back of the room.
And then the content was exquisite. The format of the session turned out to be a great idea. With only 15 minutes, each of us was required to refine our content to the cream of the cream. The order of speakers was defined by Leigh Klotz (Xerox) based on the most natural flow of thought about forms design, run-time case studies, general application architectures, and futures. Since I was talking about design, I went first. This created a happy coincidence because it made the most sense to start by announcing the most recent accomplishment the Forms Working Group, which is the transition to Candidate Recommendation of XForms 1.1. Not only did my own design-time presentation depend upon XForms 1.1, but also most of the other presenters used XForms 1.1 features as well.
With such a huge turnout, it occurred to me that quite a large fraction of people might not know much of what XForms is capable of. I started thinking back to the Compound Documents workshop of 2004 where Bert Bos, the chair of the CSS working group, said "Forms, I know what forms are. Name, address, pepperoni, extra cheese. I want to talk about more sophisticated web applications. The kind that can play games. Not necessarily Doom, but you know what I mean." When my turn came to talk at that conference, I started by launching my BlackJack form, and I played a few hands. Lady Luck was with me that day, and she was with me again on the XForms evening at XML 2007. I showed that form for effect, but then I showed a much more sophisticated "Mortgage Pre-approval Form" in both English and Chinese. Next I showed how much of the complexity of that form could be seen as simple aggregation of the concepts one can find in a reasonably small purchase order form. And at last, I launched into a 7 minute demonstration the XForms design experience for that purchase order form. You can see a video clip of that design experience here.
I enjoyed the presentations by Dan McCreary and Keith Wells because they demonstrated sophisticated applications of XForms that would be an order of magnitude harder to build with existing web application technology. During the breaks between speakers, I took the time to reiterate to the audience the business value here in terms of being able to win deals based on lower RFP bids.
I also enjoyed the two more forward-looking presentations by Mark Birbeck and Charlie Wiecha. Mark demonstrated and spoke about his experiences building a desktop application development environment called Sidewinder, which combines XForms and XHTML to allow very efficient creation of desktop applications, not just web applications. Charlie demonstrated and spoke about the applicability of the XForms architecture to creating robust mash-up applications out of components that actually are reusable.
Perhaps my overall favorite talk of the evening was given by Erik Bruchez. You can find out more about it here. Erik presented yet another application with high business value and low development effort that he created by combining XForms with the eXist database. The main point of his overall presentation was to illustrate that the XForms-based web application architecture consists of a rich client tier that can speak directly to server tier applications like databases with no coding in the middle tier. Clearly given my blog entry of Oct. 18, I couldn't agree more.
Whenever I explain that the XForms architecture is "rich client", I always stop to remind the reader that this is a mindset, not a deployment strategy. You can deploy an XForms rich client, or you can deploy XForms functionality to a thin client (a web browser only) using a server product such as the Lotus Forms Webform Server. The point is that the XForms mindset allows you to factor out the deployment issue and focus on what the application is supposed to do.
And as an IBMer, I am duty bound to my colleagues over in Information Management to point out that the database involved in the above mentioned example could instead be the scalable and robust DB2 9.x with pureXML support. Using a package like Lotus Forms that supports the XForms 1.1 submission enhancements for web services and REST-like services, forms applications can directly consume web services set up by the database adminstrator without the need to bring in a java developer to write the code in the middle. This is an important point that I'll return to very shortly in the conclusion.
The final presentation was the keynote by Elliotte Rusty Harold, who is a gifted speaker and thinker. He began by explaining how hard it has been over the past 15 years to make do with today's web architecture for building web apps. He was more eloquent at saying this, but it's a bit like trying to incrementally build a 15 storey building on the foundation for a single family dwelling. Of course, the point was that XForms can do the job that today's web just can't, and it can do it really well, but... As Elliotte explains it, XForms is currently a "Cambridge" technology built by really smart people, and that it needs to build the bridge to New Jersey where all the fast-and-cheap, quick-and-dirty... and successful... technologies live.
This is a fancy way of saying that while XForms is now hardened for the most demanding of enterprise applications, more focus is needed on making XForms more accessible to the much wider audience of people who perhaps start out with simpler problems that work their way up into being the complicated beasts that become those unmaintainable piles of jumble-fuss (my word; Elliotte would've come up with a better one) that cause so much trouble today.
XForms can win, Elliotte says, if three things happen. First, native support in the browser. Second, good design tools. Third, XForms needs a killer app.
Regarding browser support, he points out that it is well-known that IE will be hard, but that we should start out by getting the Firefox/Mozilla XForms plugin to be moved to the core browser, and not an 'additional' plugin anymore. To some extent, I agree, but in the spirit of New Jersey thinking, XForms can already run in all browsers because we have server-side products that can boil it down to the HTML and AJAX that all browsers, including IE, natively understand. Elliotte felt that was a bit of a hack, but we have to remember that he's also a professor, so he sometimes also falls into the Cambridge trap. Still, the point is well-taken, as long as we view things in terms of transition. The server products show that XForms is a viable technology for all browsers even if you don't want to deploy rich clients. A great next step, of course, to garner direct browser support, and we're working on it, but it's not impeding our ability to provide the business value of XForms to customers today.
Finally, there's Elliotte's point about needing a killer app. Let me start with a Cambridge thought: XForms doesn't need a killer app because XForms is the killer app. The first killer app of computing was the word processor; the second was the spreadsheet. In a conversation I had with Elliotte the next day, he commented that the spreadsheet was even more of a killer app because it had to move the coder out of the way in order to put the computing power in the hands of the people. Sound familiar? XForms is the killer app of Web 2.0. The New Jersey reality check is that it has to walk like a killer app and quack like a killer app in order to be a killer app. The spreadsheet only became the killer app once the people saw what they could do with it and how to do it. The 'what' and the 'how', that's what made the XForms + database presentation and the design tool presentation so important in our XForms special session at XML 2007. The call-to-arms is simple: make more what, make more how, ... make XForms Everywhere.
Well, I haven't blogged for the last couple of weeks because, as it turns out, I was swimming with the sharks!
Well, actually, I tried my best not to be in the water when a pair of hammerheads and a trio of grays came callin', but one morning my wife and I had to rush into the water to help an older man who was merrily floating along, ears below the water line and a pair of hammerhead fins vectoring his way.
Otherwise, a peaceful and restful vacation and back in the XForms saddle. And while I was away, the W3C publication process did indeed unfold as expected (with a little help from Steven Pemberton) to allow delivery of the latest working draft of XForms 1.1
Notice that the above link takes you to the diff-marked version of the spec. These show the differences between the current working draft and its predecessor, which was published in December of 2005. If you have familiarity with the prior spec, this allows you to see the new things that have made it into XForms 1.1, and the changes to existing features of XForms 1.1
There are quite a few smaller tweaks here and there, but I'll focus a bit here on the big ticket items. One is the effort the XForms team has been putting into the access that XForms authors will have to event context information in XForms actions. This is going to be a very powerful addition to the language. The other major area of change involves the addition of features to the XForms submission module. The goal of these changes is to open up XForms to a wider variety of sympathetic web technologies. Frankly, there is an interplay between the changes we made to submission and to event context. Expect some further changes and additions in the next working draft.
A small change that has, perhaps, the most important and far-reaching implications is the namespace URI that will be used for XForms 1.1. This is a very challenging issue, but the net is that XForms 1.1 will use the same namespace URI as XForms 1.0. Like those sharks, this really bites in some ways, but also like the sharks, it turns out to be unavoidable. Stay tuned, and I'll tell you why in an upcoming blog entry.
A lot of talks about XForms are a bit technical in nature because the people who manufacture XForms processors tend to be technical people who understand the business value of XForms in terms like "model-view-controller" architectures, a superset of AJAX, and software engineering benefits like abstraction. But the C-level executive cares not about these things. It is important to connect them to what the C-level executive does care about.
The C-level exec is about efficiency, flexibility and accountability.
The CEO wants
- efficiency via reduced operating costs and decreased time to close deals
- flexibility to react to new business processes and changes of business partners
- accountability for control of expenditures and compliance with regulations
The CIO wants to achieve
- efficiency through end-to-end business process integration and ability to leverage business objects as IT assets
- flexibility through a malleable system architecture that can be rapidly reconfigured with replaceable, reusable components
- accountability through transaction record auditability
We need to speak about how XForms helps the organization to achieve better results along these metrics. This is where the global picture of what XForms does against the backdrop of the classic 3-tier architecture comes in handy.
The C-level exec is not up at night worrying about the server tier, where databases, content managers and workflow engines live. These may be expensive systems, but they are designed to be robust and highly scalable systems whose metrics relative to the size of the anticipated user base of a system are easier to quantify. In other words, they are low risk numbers that are easy to budget for.
The C-level exec is not as concerned about the client tier, where the browser and OS live, again because the metrics are easy and stable.
The C-level exec has the most uncertainty and risk at the middle tier. There are two parts to it. There is the part that uses APIs to talk to DBs, CMs and workflow engines to implement custom application logic as needed. This part is not as scary because we have reliable, robust, scalable, stable APIs, and because the components we're talking to are those reliable, robust, scalable, stable, expensive systems sold by companies with important people's ties to yank when there is a support problem. Then there's the scary, assembly-language-of-the-web-part of the middle tier. This is the part that has to juggle a dynamic, multistep end-user experience on the anything-goes client side, where the web browsers are free and you get what you pay for. The upfront cost of the thin client is low, but the time to market with new offerings is the most highly affected because a lot of unpredictable, time-consuming work lives here.
- It allows you to standardize and consolidate the end-user experience into a single business object that represents the overall transaction.
- It allows that business object to access the web services of an SOA as a natural part of the process of going from empty transaction data to completed transaction data.
- It fully represents the transaction and therefore can function as an integral part of the records needed for auditability.
As a final thought, it should be clear from the exponential scales of complexity and cost that the diagram above argues that XForms-based systems have business value through complexity containment, and that said value is rightly reflected in software product cost.
At the specification level, the W3C Forms working group is working on modularization of XForms as one means of promoting incremental adoption. This is following the simple business axiom that "embrace and extend" is economically preferable to "rip and replace". If you have existing web applications, and you want to start incorporating selected features of XForms to get at certain benefits, it helps to be able to get at just those features without having to change your entire application over to XForms in one development cycle. Modularization supports agile development.
The Forms working group is now also working on XForms 1.2, even as XForms 1.1 continues toward full W3C Recommendation status. In XForms 1.2, the second approach the Forms working group is using to promote incremental adoption is to stream-line web application authoring through emphasis on attribute decoration and exploitation of UI element nesting as a means of expressing the simpler classes of MVC applications. The attributes are attached directly to UI elements, but they imply a proper XForms MVC architecture. In other words, the XForms processor can read the attributes and auto-generate a proper model for you. To get an idea of what the stream-lined vocabulary might look like, and what canonical XForms it might correspond to, look here.
The approach of providing stream-lined syntax is simpatico with modularization for two reasons. First, it means we can provide the stream-lined vocabulary and processing model as a module separately from modules that provide the components of the core XForms engine (e.g. the instance data module, the submission module, and so forth). Second, the stream-lined syntax approach means that authors can start with attribute decoration and UI nesting, and then scale up in more complex functional areas as the need arises by adopting the core XForms modules appropriate to the problem at hand.
The stream-lined syntax approach is also interesting because techniques such as attribute decoration, UI nesting, and progressive elaboration of a document are techniques familiar to AJAX developers and made popular by AJAX libraries such as Dojo. In fact, I am really coming to the conclusion that AJAX libraries are a viable alternative to browser-maker adoption as a means of delivering the most web-centric components of the W3C technology stack. It should not be necessary for Microsoft, Mozilla, Apple, Opera and other browser makers to build a W3C technology into their browsers before it becomes widely adopted and deployed. More importantly, this means that the W3C, not the browser makers, defines the web and its standards.
A few posts ago I promised to get back around to the discussion of the namespace and versioning of XForms 1.1.
In the early days of XForms 1.1 (late 2004), we expected to upgrade the namespace URI as the means of indicating which processor should be used to interpret the XForms vocabulary within a document. There were, after all, not just new elements but also new attributes for existing elements and in some cases slightly adjusted behaviors for the same elements.
Well, a lot can happen in 18 months! For one thing, we originally intended to publish XForms 1.1 as the upgrade to XForms 1.0, but since then we decided to focus more heavily on the excellence of XForms 1.0, resulting in the publication of a significant body of errata. Those have since appeared in the new W3C Recommendation for XForms 1.0 in March of 2006. We have since published some further errata, and I expect we will publish an updated errata list in the next few weeks. This has allowed XForms 1.1 to become much more about the new features and less about the behaviors of existing features.
The second thing that change is that we decided that an important aspect of increasing XForms adoption was to make it easier for web content authors to write. For this reason, the HTML working group communicated the need to import the XForms module directly into the XHTML2 namespace rather than leaving it in the native XForms namespace. To accommodate this requirement, we created the notion of a chameleon namespace in the schema for XForms 1.1. This concept allows us to define XForms in the XForms namespace, but it allows a host language like XHTML to more easily import the XForms vocabulary by substituting its own namespace instead of the default XForms namespace.
Of course, any host language that attempts such an import has to deal with possible name conflicts, and we did encounter some, like the src attribute. We had to do some jiggling of both XHTML2 and XForms to smooth the integration. This is interesting to note because you can't expect XForms to change for every host language. We did this more as a one-off for XHTML to help increase adoption. Generally, XForms remaining in the XForms namespace is preferrable because it is easier for a wider array of XML-based tools (like XSLT) to find the XForms content if it stays in its own namespace. However, there is a special heritage for web content, so adding the chameleon namespace to XForms and making other technical adjustments was part of our effort to cater to backward compatibility needs and ease of authoring needs.
So, to be clear, XForms content should remain in the XForms namespace whenever possible, such as when used with host languages other than XHTML, because there are significant technical benefits to doing so.
Now, how does this relate to the versionining of XForms or the fact that XForms 1.1 will use the same namespaces as XForms 1.0? Well, along separate lines, the XForms working group had received a number of communiques indicating that the change of namespace made it harder to write software that processed XForms content in ways that were not necessarily affected the vocabulary changes. Basically, the change of namespace was viewed as costly to the community. While mulling over this feedback several months ago, I realized that people who were dissatisfied with our change of namespace URI between XForms 1.0 to XForms 1.1 could simply use the chameleon namespace feature to put the XForms 1.1 markup into the XForms 1.0 namespace. They didn't have to use the feature to put the markup in the namespace of a host language.
This thought was very good news for solving the problem of those who wanted us not to change the namespace of XForms in 1.1. Since the chameleon namespace feature could defeat the intent to use the namespace URI to control the language version, clearly we had to change to versioning 'within' the XForms vocabulary. Hence, you can see in the latest working draft of XForms 1.1 that we now have reverted to the one and only XForms namespace URI originally allocated in 2002, and we have added an internal version attribute on the XForms model, defaulting to 1.0, to indicate the version of the language.
Well, no blogs from me next week, so seems a good idea to knock off another one this week...
XML namespaces rec (pardon the pun) states that an attribute which is namespace unqualified
is 'local' to an element and is uniquely identified by a combination of the attribute local name and the type and namespace URI of the containing element.
The word identify
really should be used more sparingly, as here is a case where its misuse has caused years of confusion and acrimony in the XML community. An identifier is something that established the identity of something else. You cannot have two things associated with the same identifier unless they are identical things.
I am often frustrated by seasoned W3C folks who say that "this depends on your definition of identify" and honestly
believe this is a defense of the confusion in the namespaces rec. This is like saying ot me, "Well you're right unless you have a definition for identify that doesn't identify things, which is what we
did at the W3C."
To see the problem, you have to look earlier in the spec where a namespace n1 is associated with a URI and then the following code appears:
<good a="1" n1:a="2" />
The problem is that the element 'good' is in the same namespace as n1. So now you have local attribute a
that is essentially given meaning by an element that is in the same namespaces as the 'global' attribute n1:a
. Yes the two attributes have different values.
From this we have to infer that, although a local attribute is given meaning based on the containing element and its namespace, a global attribute with the same local name and namespace qualified into the same namespace can actually mean something totally different.
In other words, we have two attributes with the same local name, contained by the same element, and given meaning by the same namespace URI, but they are not identical. This is the local attribute not
being 'identified' (in my sense) by local name and containing element type and namespace.
The technically subtle W3Cer will tell you that there was no reason to spell out using words in the normative part of the spec the fact that the two attributes are different things because the spec says that local attributes are in a different partition than global ones. Problem is, this partitioning info is in a non-normative part of the spec, and particularly in the same part that has the language about how local attributes are 'identified' by local name and containing element type and namespace.
Anyway, the upshot is that an XML vocabulary does not need to but is allowed to say that local and global attributes with the same local name can mean different things. If they're supposed to mean the same thing, then the XML language has to define a precedence rule for what happens if the two attributes differ in value. Here's an example:
<data xmlns="http://example.org" xmlns:ex="http://example.org">
<price currency="USD" ex:currency="EUR">10</price>
Question: Is the price in USD or Euros?
Answer: Depends on who designed the language.
Second answer: Don't do that.
Interestingly, the XHTML working group came up with a fascinating example where it is legitimate and sensible to have a global and local attribute with the same local name but completely different meanings. It has to do with the next version of XML events. After hours of discussion, the decision was that they weren't going to do that (second answer above). Not because it's illegal, but because it's too subtle for most XML people.
Well, the XHTML group may change their minds, but even if they don't, the example is really worth understanding because it actually makes sense why you'd want to have the two attributes mean something different. Stay tuned, I'll tell you all about it when I get back...[Read More
new release of our forms software, version 4.0, is now only a few weeks from shipping. And as of this release, the product line will be known as IBM Forms
! This is an incredibly important indicator of the strategic value IBM sees in the Forms business as a key component in building a Smarter Planet. The feature set coming in this new major release combines the best of Web 2.0 client application behaviors and design experience with the traditional strength of interactive XML data collection for which the prior releases our product line are well known. IBM Forms documents are interactive web application instances that have many traditional capabilities that we have been building into them since 1993.
- They can always be serialized to provide a user with their own saved copy of their web application experience, to archive, to email, or to pass to the next step of a business process or workflow. They can be reinstantiated at any time to continue the interactive fill experience.
- They can be instantiated directly into a web browser without using a plugin, and they can also be instantiated in a client application for an offline fill experience, dramatically simplifying IT maintenance and platform support, .
- They provide a multipage high precision visual layout with comprehensive accessibility support and localization
- They operate over XML payloads that directly conform to the needs of back-end business functions, enabling straight-through XML processing systems.
They enable rich web application interaction and behaviors based on the W3C XForms 1.1
- They allow users to attach supporting documents into the form in support of their business function, including spreadsheets, word processing files, images, videos, etc.
- They secure the business function implemented by the form with a comprehensive interactive document digital signature system that includes sectional signing, multiple signatures, and overlapping signatures, all of which protect not just the form data, but the form behaviors, the form appearance and the attached documents as well.
Now lets add to that what's coming in the new release:
- The ability to drive customer satisfaction and employee productivity through more efficient, compelling interfaces that can include
- gradients, border styling, thematic color control, combined text and images
- AJAX-driven XML web service updating without web page refreshing,
- formatted HTML text for bold, italic, underline, text colors, font control, lists, hyperlinks, etc.
- Embedded custom HTML extensions and popup dialogs that can show maps or movies or even interact with the running form.
- The ability to deliver integrated solutions faster and spend less time and money maintaining them through a comprehensive new set of Design Experience features including
- Form Parts that make it easy to reuse and maintain common components consisting of one or many user interface controls and corrresponding behavioral markup
- Data-driven form design with XML schemas that define back-end data formats; data type sensitive automatic user interface creation, including tables and label annotations
- Web service integration wizard that provides point-and-click, drag-and-drop web service consumption and user interface mapping.
- The "wizard of wizards" that enables rapid development or addition of a step-by-step wizard experience for a form
- SVN source code repository interaction, Integrated Design Time spell-checking, etc.
- The ability to use your Forms solutions how you want and where you want, including
- An automatic forms view portlet and support for Portal 7.0 and Mashup 2.0
- Updated browser and OS support and improved integrations
- Improved workflow system integrations with Filenet and Websphere BPM
- Webform Server support for the iPad
The real achievement here is not just these new features, but getting them to work well with all the traditional features. IBM Forms 4.0
, coming soon to a Smarter Web Application near you.
The title of this blog has changed to begin "IBM Lotus Forms..." yet many of the prior entries on this blog refer to "IBM Workplace Forms...". This is because, as of the next major release, Workplace Forms is transitioning to "Lotus Forms".
To me, this transition positions the Forms product line squarely among the top-of-the-heap offerings by the Lotus division. Based on the overall technical direction announced at Lotusphere with Quickr, Connections, Expeditor, and Notes, as well as the clear place that Forms has in that technical direction, you can see that great things are coming for IBM Lotus Forms.
In "enterprise" service-oriented architectures (SOAs), XML is a clearly entrenched format for server-to-server communications. But there's a movement afoot to define a "Web SOA" as a separate entity that describes server-to-client communications... based on JSON as the format.
The rationale is that JSON parses "a hundred times faster" in a web browser than does XML. This is like the tail wagging the dog. It is a myopic, accept-the-status-quo approach to web application computing, and it just won't do.
First of all, the difference between parsing different serializations is negligible (when done right), and nodes are nodes are nodes, so if there is a 100-fold difference, it is because one parsing method is direct and the other is doing something phenomenally suboptimal and probably easy to fix. One way to solve this is to alter all the system architectures on the web and introduce the complexity of a data format transformation to cross the illusory chasm between a "Web SOA" and the "Enterprise SOA". Another idea would be to put the pressure where it rightly belongs, on web browser makers to fix the feature of efficient XML processing.
Particularly as vertical industry standardization continues, such as is happening in both insurance and healthcare, this latter solution is really the only viable one in the long term. XForms technologies like Lotus Forms and Ubiquity XForms wrap a logical client application around the exact XML that is needed by the server side because this is the best way to minimize system development and maintenance costs. Once there is a defined XML data model, there should not be some other second data model introduced into web applications for some reason as vapid as poor implementation of the required feature.
This conversion is not a trifling matter either; have you seen how ugly the JSON is that is actually capable of preserving XML fidelity (i.e. supporting round-tripping)? Trying to build a reasonable client-side around that JSON is not nearly such a pretty sight as when the data representational limitations of JSON are accepted in an application. If the full representational power of XML schema is used to define an application data model, then we need to be able to carry that out to the client without significant alteration so that we can make references to the data transparently, not through the lens of some horrendous transformation. And make no mistake, XML schemas for vertical industry standards are full-featured indeed.
Finally, I would be interested in hearing about any research into whether the overall throughput of a web application is increased or decreased by the introduction of JSON down to the client. It's nice that parsing gets a hundred times faster on the client, but when you're server is trying to handle more than a hundred concurrent users, and the server has to translate from XML to JSON (and back again), then it sure seems like the use of JSON is pushing processing burden in the wrong direction.
We usually think of a document as a file. A file is, at the operating system level, a unit of information. The OS can associate properties with it (like who can read it or write it), and the file can easily be moved from directory to directory or computer to computer with standard tools like FTP, email, or flash drive.
The XML recommendation defines a document as that which conforms to BNF rule #1 of the XML syntax. Of course it is useful if an XML document is the sole content of the unit of information being transferred, i.e. if the XML is the only thing in a file. This is because XML tools tend to be built with programming languages that expose services of the operating system.
However, the most important part of an XML document is capable of being contained within another document. In fact, XML canonicalization strips away the part of an XML document that would prevent the result from appearing as element content.
This is the idea that XForms uses when it expresses XML instance data within a larger document, and specifically within the
<xforms:instance> element. Of course, the
<xforms:instance> element can also reference a whole XML document using the
src attribute, but in both cases, the result is parsed into the live running instance data. The user interacts with the XML data document, and the XML data document is what is returned to the server by an
This paradigm works well enough if you think of a form as an ephemeral view of a back-end database or content repository. However, people find it easier to work with a document in the file sense of the word. we like to save our document, email it, reload it the next day or on a new computer, and especially on a computer that has become disconnected from the net or from the original web application context that would be associated with the ephemeral view kind of form.
Enter the document-centric approach of Workplace Forms, the technological basis of which is an XML document whose element names belong to the XFDL and XForms vocabularies. Moreover, the underlying XML data document is still incorporated by the
<xforms:instance> just like all other XForms-based documents.
A key difference is that being a document implies that the form with eventually have to be re-serialized, e.g. to save or sign the form. XForms doesn't really talk about how to reintegrate the live, modified XML data back into the document, but in truth it's really not that hard. The main technical hiccup on the XForms side is that the
src attribute takes precedence over the content of
<xforms:instance>, so when the live data is synchronized back into the form, the
src attribute has to be eliminated.
The conclusion, though, is that a Workplace Form, or XFDL document, is a cross between an office document and an mobile intelligent agent. It can be saved, reloaded, printed, emailed, archived, signed, submitted to web application and portal servers, and participate in document management, records management and content repository processes. This is how the notion of document makes a form be more than just an ephemeral view of data.
A Lotus Form is a document currently expressed in an XML vocabulary called XFDL (html version, pdf version).
This is significant enough, in and of itself, to be set off in a paragraph. XML is a de facto industry standard from the W3C, and this means that widely deployed, interoperable, industry standard software toolkits can be used to introspect and manipulate the content of XFDL, i.e. Lotus Forms documents, thus mitigating issues of vendor lock-in.
But the story gets better...
The XFDL format internally employs W3C standard XForms, so without further reference to any vendor-specific documents, the standard indicates where in the XFDL document to look for the data content created by an end-user who fills in the Lotus Forms document. Anyone with access to a Java reference manual could write code to prepopulate data into an XFDL (Lotus Forms) document before it is delivered to an end-user, and they can write code to extract data from the document when it is returned to the server for processing.
But the story gets even better...
XFDL incorporates the W3C XML Signatures standard, so widely available industry standard tools are available from multiple vendors for validating the security of digital signatures in XFDL documents. In addition to the Apache XML Security implementation, it is notable that Java itself now natively contains support for XML Signatures (JSR 105).
These standards mean that the entire server-side lifecycle of the Lotus Form can be achieved without being locked into using any particular vendor's API. Any application server, any portal server, any server-side environment that can receive HTTP POSTs and process XML in the POST data can be used in combination with Lotus Forms.
And if you ever hear a vendor try to play up high availability of a client-side browser plugin for processing their favorite file format, ask them "Plugin?? What plugin??" With Lotus Forms, you don't need a browser plugin at all because the Lotus Forms Web Form Server converts the XFDL into dynamic HTML that can be processed directly by the browser with no plugins at all. Best of all, when the user finishes interacting with the Lotus Form, the resulting XFDL document is delivered to the application server endpoint, where it can be processed as XML using the standard APIs.
Well, my frieds, it seems a good time to draw your attention to a collection of available resources that can help you understand how you and your customers can address a full spectrum computing requirements, from the enterprise information application all the way down to the simple design-deploy-collect-analyze pattern for situational applications that arise throughout the enterprise
First of all, check out the Lotus Forms Enablement videos on YouTube. There are videos that show Lotus Forms in action in government, financial, and HR scenarios where enterprise-level functionality is a must. But you can also see videos on the new Lotus Forms Turbo product, which enables business users to design and deploy simpler survey style forms for themselves in a matter of minutes.
I want to make a pitstop here to plug the value of the XForms standard in creating this array of products. XForms as a language has a strong declarative component. This means that non-trivial relationships between data and sophisticated interactional and presentational objects is simply declared by the form developer, and it is up to the form run-time system to enforce the relationships. This maps very naturally to how we human beings think and work. We say things like "Whenever I get an email from domain X, put it in my super special high priority folder". We don't directly write batch jobs that run loops over our inbox to categorize our email, and even if we did, the time at which those jobs would run would be specified declaratively! In fact, I don't think it's hyperbole to say that the universe itself operates mostly on declarative laws. Gravity just happens. If you let go something, it drops. It's the law; get used to it ;-).
The point is that the declarative language constructs of XForms are what enable Lotus Forms to accelerate enterprise-level application design, to enable end-user design of simpler applications, and to ensure interoperability between these two types of applications so that the simpler situational applications can be scaled up to the enterprise level as their value becomes more broadly established. The declarative constructs of XForms accomplish all of this due to the simple fact that it is far easier to create software that maps point-and-click/drag-and-drop design experience gestures onto high-level declarative language constructs than it is to map the same things onto huge blobs of imperative scripted code from a general purpose programming language.
And don't just take my word for it. When you finish watching some of the videos at the YouTube link above, how about going for a test drive? You can get free trial downloads of the Lotus Forms, including the client-side runtime and design environments. If you like the enterprise-level capabilities, but you don't want to deploy a client-side runtime, you can also purchase the Lotus Forms Web Forms Server, which translates Lotus Forms into standard web pages. But once you're in test-drive mode with the client-side runtime viewer, check out the Lotus Forms catalog of sample forms. Finally, you can also test drive the new offering for non-technical users directly, without having to install a thing by visiting Lotus Forms Turbo on Greenhouse, or if you'd prefer to test drive it in-house, then just download it from the free trial downloads page.
Either way, once you've gotten Turbo, see a couple of the videos then think of your own simple survey app. Design and deploy it right onto Greenhouse and see how long it doesn't take!
Despite all the excitement about the possibilities that HTML5 offers for a better world wide web, I believe there is a critical flaw in the go-forward plan of those who are feeling the momentum.The problem is that they still haven't got ~80% of the web browser makers on board!By which I mean they haven't got you-know-who.
There's really only one way to break the loggerjam and move forward with advancing thestate of the web. We need to get you-know-who out of the way of progress by showingthat we can innovate on the web with or without their participation. We have now shown that this is feasible by way of the ubiquity strategy based on our abilityto deliver an interactive web application language in multiple web browsers with no client-side plugins and no server-side processing of the language. Click here to visit the project.
For all web advancement technologies, including HTML5, the longer term effect of the ubiquity strategy should be that the late bloomers are shamed into implementing the advancements, thereby obviating the need for the ubiquity code. But meanwhile the ubiquity strategy is the way to enable web advancement technologies including HTML5 to emerge (in the proactive verb sense of the word).