RE: Apple's XForms CFR Response

At the risk of entering this discussion sideways and from the
outside, I'd like to answer a couple of issues from the original note,
which I saw on the public www-forms-editor list.

This message has two parts: a soapbox, which you can skip, and a series
of numbered points responding to -- and making suggestions about --
a few of the points raised in the inditial note.

Briefly, I believe that the XForms specification document is too
complicated, but XForms itself is not.  With a couple of minor changes
to the specification, I believe that most of these concerns can be
answered, and a valuable piece of web architecture can move forward to
adoption by a large number of XHTML users.

While it may be the height of hubris for me to think that XForms is
valuable to the world at large, it is an opinion that I hold, and I
take this paragraph to expound a few more: As Benjamin Franklin said,
"We should all hang together, or we shall surely hang separately."  I
believe that it is more valuable to have such a common standard that
is extensible and forward looking, and I believe that the interests of
the billion or so desktop and mobile web users are better served by
such a standard than by Microsoft's stagnation of Internet Explorer
coupled with their apparent efforts with InfoPath to move forms into a
premium office product under the cloak of "standardization on XSLT."

Furthermore, while the Opera proposal for a common JavaScript library
is meretricious, I believe the world again would be better served by a
recommendation that works across many types of devices -- even those
that don't support JavaScript as Opera does.  (For example, Tim Bray
and I have Danger Hiptops -- a quite succesful split client device
whose $200 price (1/4 of the Ericsson P800) is possible
because of the reduced cost of components if you drop features like
floating point and JavaScript.  And I have enough parts around the
house to put together an XForms client for the device.)

Finally, XForms is usable across the many use cases found in back-end 
and middle-tier processing that often precedes the delivery to the 
browser, where the ability for other computer programs to create, 
reflect on, and transform forms and data models would be greatly 
enhanced by an XML pipeline and greatly hindered by a having to 
recognize and partially evaluate JavaScript idioms.  I know this to
be the case, because we are using XForms in Xerox in a .NET-based
Web Services system where job templates are defined in a web browser,
based on the result of procesing service configuration templates 
defined in the web services as simple documents containing an XForms model 
and UI controls.  I mention this complex use case involving Web Services
only in order to show that XForms has broad applicability in XML
and Web Services systems beyond what can be done with JavaScript libraries
in current web browser products.  I'm given to understand that
Novell's J2EE product and Oracle's Mobile Server also use XForms in
a similar way.  Thus, XForms has already proven its worth in middleware,
and the ability to carry this vocabulary through to clients of all
stripes -- mobile/PDA/cell desktop, WAI-flavored -- would be much 
more beneficial to the billion or so people I mentioned above than
would a series of incremental hacks on HTML that leave the real
innovation to expensive desktop clients and and pay-per-click form filling
solutions for business.

Having set my opinion forth, I now want to turn to a few of the factual 
issues laid out in the original comment and attempt to address them.
I don't pretend to address them all, and certainly I concede a few and
offer helpful suggestions (ahem) for the Working Group on some of them.

1. XForms requires XML Schema.
We tried very hard to make sure that XForms did not require XML
Schema.  If a Schema is present, it can be used to validate the
instance document structure, and to provide types.  But if no Schema
is present, you lose only validation of structural changes to the
instance, and user-defined types.  Schema Part II data type validation
can be done on the basis of string comparisons, and is well within the
power of even mobile XForms clients.  I would expect that most XForms
processors that are not written from scratch would include XML Schema
validation only if they already have a library present.  In fact,
earlier versions of XForms included a "Basic Profile" that dropped XML
Schema processing, but as there were no XForms implementations on
small devices that lacked XML Schema processing, it was dropped.  I
believe that Safari, Opera, and Mozilla are excellent candidates for
such an implementation of XForms.  (In fact, if you check the Bugzilla
records, you'll see a conversation between me and Dave Hyatt where Dave
agrees that such a course would work for Mozilla.)

2. Too many namespaces.
I think we're all familiar with Tantek Çelik's proposal that there be
only one W3C namespace, and with the general opposition to XML
Namespaces that appears on public discussion lists such as
XML-DEV. I'm quite sympathetic to Tantek's proposal, and I think
that the W3C should have taken a look at it, yet here we are,
  Modularity is a 
necessity in an extensible language, and namespaces are a mechanism 
by which we achieve it.  The end results, though, are not kind to authors
So our options are smoothing and mitigation, not a wholesale rejection 
of any modularization of extension just because XML Namespaces exist!

As for smoothing and mitigation, ff the XForms working group were to agree
to one small change for Recommendation, then XHTML would be able to
incorporate all the XForms elements into its own namespace, and the
prefix madness would go away.

To wit: The XForms specification should allow the inclusion of the XForms
elements into any namespace, a goal achievable by making the normative
Schema into a "chameleon" schema and adding a sentence about
namespaces to the specification.  Unfortunately, we were not able to
achieve consensus on this issue for PR.; here's hoping that this
feedback will spur the XForms Working Group to try again for consensus
on this issue.

3. Too much dependency on other specifications
I've already dispensed with XML Schema and XML Namespaces above.  I
guess this leaves us DOM, XML Events, XPath, and CSS.  

I'll lump DOM and XML Events together, since XML Events is 
syntactic sugar (if XML syntax be sugar) for DOM Events.  
Broadly speaking, browsers supporting JavaScript already have DOM, 
so it's a simple syntax issue, and I believe, de minimis.

As for CSS, it is not required, in theory or practice.  I believe that
if popular browsers implemented XForms but not CSS Level 3, and just
took the effects described by the appendix F.3 and hard-coded them,
pretty much everybody would be happy for quite some time.  CSS is
provides a model for styling, but there is nothing in the XForms
conformance that requires it, and in fact, a user agent could simply
provide a built-in set of styles for XForms elements that makes them
look just like XHTML elements, and has hard-coded styles for elements
such as alert that "do the right thing."  As with ignoring XML Schema
declarations, I would heartily recommend this approach for
implementations in current popular desktop browsers.

Note that CSS styling for the model elements can be hard-coded to
"display:none", help can be a hyperlink on the label, hint can be a
tooltip, etc.

XPath, then, is perhaps the most objectionable external dependency.  
I'll address that next.

4. Too hard for authors.
Certainly, the XForms specification is too hard for authors.  And the
XForms books aren't out yet.  But one issue I think has been severely
underplayed is the "lazy authoring" methodology that XForms supports.
As all of the implementations of XForms to date have necessarily been
done by proponents of the standard, they are all also experts in it,
and have not paid much attention to this critical feature, but it does
in fact exist and I believe is implemented.  This very important
feature allows for fairly smooth transition to XForms from XHTML.

Briefly, the "lazy authoring" feature allows an XHTML hand-author to
write an form without an initial instance, and specifies rules by
which the initial instance is constructed.  Taking into account items
1-3 and lazy authoring, here is what a simple form looks like, in a
version of XHTML that includes the XForms module.  (Additionally, note
that there is no XForms requirement that the model be in the HTML
head.  It's a separation of concerns argument applied to XHTML itself,
and of course it need not be.  But it is not an XForms issue.  In this
section, I will assume friendliness over cleanliness and allow the
XForms model anywhere in the XHTML document.)  To further make my
point, I will use XHTML tables for layout, just in order to show that
you can.

In other words, here is what I think a real-world XForms form in an
XHTML document written by an average person and delivered to a browser
would look like:

<html xmlns="http://www.w3.org/2003/xhtml+xforms"> <!-- not a real namespace
-->
  <head>
   <title>Buy</title>
  </head>
  <body>
   <model>
     <submission action="http://www.example.com/cgi-buy/buy.pl" />
   </model>
    <table>
     <tr><td>
       <select1 ref="product">
         <label>Product</label>
         <hint>What do you want to buy today?</hint>
         <help src="http://www.example.com/buy/help/product" />
         <item><label>Pizza</label><value>pizza</value></item>
         <item><label>Pasta</label><value>pasta</value></item>
         <item><label>Porridge</label><value>porridge</value></item>
       </select1>
     </td><tr>
     <tr><td>
       <input ref="quantity">
         <label>Quantity</label>
         <hint>How many would you like to buy?</hint>
         <help src="http://www.example.com/buy/help/quantity" />
       </input>
     </td></tr>
    </table>
    <submit submission="buy"><label>Buy</label></submit>
    <hr />
      <p>Brought to you by <a href="/">Example.com</a>.</p>
  </body>  
</html>

Note that we get pretty much parity with XHTML in terms of complexity,
and we get help and hint done automagically.  We get no validation,
though, because validation necessarily requires some constraints, and
a simple instance.  But for the really common simple bounded number
case, we provide the range control, so the simple author can get range
of numbers done this way, in this example, a slider or dial or menu
number picker of 1-100.

<html xmlns="http://www.w3.org/2003/xhtml+xforms"> <!-- not a real namespace
-->
  <head>
   <title>Buy</title>
  </head>
  <body>
   <model>
     <submission action="http://www.example.com/cgi-buy/buy.pl" />
   </model>
    <table>
     <tr><td>
       <select1 ref="product">
         <label>Product</label>
         <hint>What do you want to buy today?</hint>
         <help src="http://www.example.com/buy/help/product" />
         <item><label>Pizza</label><value>pizza</value></item>
         <item><label>Pasta</label><value>pasta</value></item>
         <item><label>Porridge</label><value>porridge</value></item>
       </select1>
     </td><tr>
     <tr><td>
       <range ref="quantity" min="1" max="100">
         <label>Quantity</label>
         <hint>How many would you like to buy?</hint>
         <help src="http://www.example.com/buy/help/quantity" />
       </range>
     </td></tr>
    </table>
    <submit submission="buy"><label>Buy</label></submit>
    <hr />
      <p>Brought to you by <a href="/">Example.com</a>.</p>
  </body>  
</html>

This form upgrades seamlessly to provide other XForms features such as
client-side validation, "hidden" fields, etc, just by inclusion of the
model instance data, which looks exactly like the data that gets
submitted to the buy.pl Perl script on the other side.  So, for
example, the instance data could in fact come from the perl script in
the first place! Note that in order to implement a stable shopping
cart (where browser cookies are used for user identity) I have to add
only the line
   <instance src="http://www.example.com/cgi-bin/get-cart.pl" />
and all that script has to do is print out something like this
   <instanceData>
     <product>pizza</product>
     <quantity>3</quantity>
   </instanceData>

And here is the form again with the one-line change.

<html xmlns="http://www.w3.org/2003/xhtml+xforms"> <!-- not a real namespace
-->
  <head>
   <title>Buy</title>
  </head>
  <body>
   <model>
     <instance src="http://www.example.com/cgi-bin/get-cart.pl" />
     <submission action="http://www.example.com/cgi-buy/buy.pl" />
   </model>
    <table>
     <tr><td>
       <select1 ref="product">
         <label>Product</label>
         <hint>What do you want to buy today?</hint>
         <help src="http://www.example.com/buy/help/product" />
         <item><label>Pizza</label><value>pizza</value></item>
         <item><label>Pasta</label><value>pasta</value></item>
         <item><label>Porridge</label><value>porridge</value></item>
       </select1>
     </td><tr>
     <tr><td>
       <input ref="quantity">
         <label>Quantity</label>
         <hint>How many would you like to buy?</hint>
         <help src="http://www.example.com/buy/help/quantity" />
       </input>
     </td></tr>
    </table>
    <submit submission="buy"><label>Buy</label></submit>
    <hr />
      <p>Brought to you by <a href="/">Example.com</a>.</p>
  </body>  
</html>

In order to get client-side validation, I actually don't have to
change my client!  Having your XForms processor understand "xsi:type"
is not that hard, especially if you restrict it to the types defined
in XML Schema Part 2 Datatypes, and doesn't require any XML Schema
processor anyway, just a couple of hard-coded test cases.  So, in
order to make sure that the user can't enter a non-numeric amount in
the input field, I change my get-cart.pl script to output this.  (Yes,
the namespace strings are a little pesky, so get your favorite Perl or
Python or Java library to do it automatically for you when you set a a
type on an element!)

   <instanceData xmlns:xsi="http://www.w3c.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
     <product>pizza</product>
     <quantity xsi:type="xsd:integer">3</quantity>
   </instanceData>

Now with that simple type declaration, we get client-side validation
of numeric input fields.  But we'd probably like to tell the user that
that's what's going on.  So, assuming we're not using the range
control to prevent them from making the mistake in the first place --
maybe it's inconvenient to specify an upper bound, for example, we get
the following one-more-line change in the form.

<html xmlns="http://www.w3.org/2003/xhtml+xforms"> <!-- not a real namespace
-->
  <head>
   <title>Buy</title>
  </head>
  <body>
   <model>
     <submission action="http://www.example.com/cgi-buy/buy.pl" />
   </model>
    <table>
     <tr><td>
       <select1 ref="product">
         <label>Product</label>
         <hint>What do you want to buy today?</hint>
         <help src="http://www.example.com/buy/help/product" />
         <item><label>Pizza</label><value>pizza</value></item>
         <item><label>Pasta</label><value>pasta</value></item>
         <item><label>Porridge</label><value>porridge</value></item>
       </select1>
     </td><tr>
     <tr><td>
       <input ref="quantity">
         <label>Quantity</label>
         <hint>How many would you like to buy?</hint>
         <help src="http://www.example.com/buy/help/quantity" />
         <alert>Please pick a number!</alert>
       </input>
     </td></tr>
    </table>
    <submit submission="buy"><label>Buy</label></submit>
    <hr />
      <p>Brought to you by <a href="/">Example.com</a>.</p>
  </body>  
</html>

Now, along comes globalization, and we get told we have to
internationalize our poor form.  If the processor supports xml:lang
differential processing, that's great.  But if not, the Accept
Language header of HTTP allows a very simple mechanism to pull the
text out of the form and into a separate language bundle, where it can
be edited by people who are unfamiliar with the form operation and
layout, and translated, changed, etc.  It's a simple *evolutionary*
step from this hand-authored form above to one that is
internationalized! And it uses the same skills that we built above in
providing initial instance data -- a simple XML document stored on the
example.com web server.

First here is our internationalized form:

<html xmlns="http://www.w3.org/2003/xhtml+xforms"> <!-- not a real namespace
-->
  <head>
   <title>Buy</title>
  </head>
  <body>
   <model>
     <instance src="http://www.example.com/cgi-bin/get-cart.pl" />
     <submission action="http://www.example.com/cgi-buy/buy.pl" />
   </model>
   <model id="text">
     <!-- This will get the default text or the server will search for
          translations -->
     <instance src="http://www.example.com/text/buy/" />
   </model>
    <table>
     <tr><td>
       <select1 ref="product">
         <label model="text" ref="product/label" />
         <hint model="text" ref="product/hint">
         <help src="http://www.example.com/buy/help/product" />
	 <!-- We plucked the rest of this select1 out and put it in the text
file
              And replaced it with this one line: -->
         <itemset model="text" ref="products/items" />
       </select1>
     </td><tr>
     <tr><td>
       <input ref="quantity">
         <label model="text" ref="quantity/label" />
         <hint model="text" ref="quantity/hint" />
         <help src="http://www.example.com/buy/help/quantity" />
         <alert model="text" ref="quantity/alert" />
       </input>
     </td></tr>
    </table>
    <submit submission="buy"><label>Buy</label></submit>
    <hr />
      <p>Brought to you by <a href="/">Example.com</a>.</p>
  </body>  
</html>

And here is the static text file for English, and the web server can
be configured to append the language suffix in a rewrite rule.  I'll
leave the French translation up to la lettrice!

http://example.com/text/buy/en_US.xml
<text>
 <product>
  <label>Product</label>
  <hint>What do you want to buy today?</hint>
  <items>        
    <!-- note these items are plucked directly from the previous version of
the XHTML file -->
    <item><label>Pizza</label><value>pizza</value></item>
    <item><label>Pasta</label><value>pasta</value></item>
    <item><label>Porridge</label><value>porridge</value></item>
  </items>
 </product>
 <quantity>
  <label>Quantity</label>
  <hint>How many would you like to buy?</hint>
  <alert>Please pick a number!</alert>
 </quantity>
</text>

  
 


-----Original Message-----
From: Håkon Wium Lie [mailto:howcome@opera.com] 
Sent: Thursday, September 04, 2003 3:44 AM
To: Mark Birbeck
Cc: 'Wanda Cox '; 'w3c-ac-forum@w3.org '; 'team-xforms-review@w3.org ';
'www-forms-editor@w3.org '
Subject: RE: Apple's XForms CFR Response




Also sprach Mark Birbeck:

 > [I'm aware that your posting is part of a formal procedure, and not for
 > soliciting comments, but I feel that one of your central points is more
an
 > issue of presentation of the spec, than of the spec itself, so I hope you
 > don't mind my comment.]

In light of Roger Cutler's recent request for more exciting messages
on this list, your comments are most welcome :-)

 > > Claim 3: XForms has striven to improve authoring. 
 > > Counterclaim: XForms is, in our experience, orders of magnitude harder
 > > to author than HTML forms. For example, compare ...
 > 
 > The spec has not focused on showing how to make forms simple, but that
 > doesn't mean it isn't possible.

   [example and arguments cut]

 > It would be difficult to argue that this is hard to learn! On the
contrary,
 > the fact that there is not a line of script in sight, should make this a
 > breeze for most web programmers to pick up, make it quicker (and more
 > accurate) to test, and easier to deploy across platforms.

By developing and standardizing library of "form functions",
JavaScript can also be removed without using XForms. Things to note in
the example below:

    * Does exactly the same as the XForms example, except that it
      works _right now_ in good XHTML+CSS+JS browsers.

    * No namespaces.

    * No XPath.

    * Fewer elements (ignoring those that were omitted from the XForms
      example, anyway).

    * Two event handlers, but just referring to a function in a
      generic library.

    * Easier to author, since it doesn't use any new technologies
      and authors are therefore already familiar with it.


<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
   <title>Hello, World!</title>
   <script type="text/javascript" src="library.js"/>
   <style type="text/css">
    input[readonly] { border: none; background: transparent; color: inherit;
                      font: inherit; display: inline;`width: auto;
text-align: right; }
   </style>
  </head>
  <body>
   <form action="">
    <p>
     <label>
      Choose a Greeting
      <select name="greeting" onchange="propagateValue(event)" size="1">
       <option value="Hello">Hello</option>
       <option value="Goodbye">Goodbye</option>
      </select>
     </label>
    </p>
    <p lang="fr">
     <label>
      Choissisez une Salutation
      <select name="greeting" onchange="propagateValue(event)" size="4">
       <option value="Hello">Bonjour</option>
       <option value="Goodbye">Au Revoir</option>
      </select>
     </label>
    </p>
    <p> <input name="greeting" readonly="readonly"/>, World! </p>
   </form>
</html>

I can sympathize with the desire to remove JavaScript. Indeed, I
argued for several features in CSS (e.g. hover effects) on the basis
that they replaced JavaScript. However, I don't see that replacing
JavaScript with XPath is a huge step in the right direction as writing
XPath expressions is very similar to programming. XPath may not be
Turing-complete at this stage, but seem to be heading quickly in that
direction. What I see is that introducing XForms on the web represents
a huge complication for authors and tool makers while not achieving
much beyond what can be already be achieved interoperably today.

Opera Software has been working on an XHTML module which would add
some functionality from XForms (e.g. basic data typing and XML
submission) without introducing large numbers of extra dependencies.
We hope to continue this work in cooperation with W3C and its members.

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome

Received on Thursday, 4 September 2003 14:21:01 UTC