W3C home > Mailing lists > Public > www-forms@w3.org > November 2002

How you can help: Interoperability (The Knowing - Doing Gap)

From: Sebastian Schnitzenbaumer <schnitz@webaccess.mozquito.com>
Date: Tue, 26 Nov 2002 05:44:29 +0100
Message-ID: <5625241.1038281893824.JavaMail.SYSTEM@webaccess>
To: <www-forms@w3.org>

Hello forms community,

time to focus on what really needs to be done to finish XForms 1.0.

Your help is needed. Here is how:

XForms sets the bar at W3C being the specification that has by
far the most implementations at CR stage. No other W3C technology
has had so many implementations at Candidate Recommendation.

This is goodness. And this is rare. Typically a Rec comes out and
we wait a while to see multiple implementations. My impression is
that many individuals still operate in this mode, believing that there
is still room to discuss issues on an abstract basis as if there were
no implementations.

Whether you like or not, the new breed of browsers that will matter
in the future are among those now called X-Smiles, FormsPlayer and
Novell XForms Explorer, and others. Time to put the Netscape vs. IE
thinking aside. More important for now, all three of those browsers
mentioned support for the new XForms CR spec.

CR is about implementation feedback. A W3C specification is
primarily targetted towards implementers, not authors or end-users.

The XForms WG is aiming to reach interoperability amoung those
implementations that support the CR spec. If you have ever tried
to author an XSLT than runs in more than one implementation, you
will understand how rare it is to reach such a level of interoperability
before a specification becomes a final Rec.

Learning from past experience at W3C, XForms now has the potential
of reaching this kind of true interoperability before the spec is carved
in stone, avoiding millions of dollars in extra time in the future for web
developers having to figure out how to deal with multiple, slightly
different implementations. The XForms WG is willing to go this extra
mile, while others in the past didn't.

In order to achieve this, we need your help. We need you to
actually sit down, write XForms, and try to make them work in as
many CR implementations as possible.

If you think you've found an ambiguity in the spec, but haven't checked
whether it has actually been implemented differently in the CR
implementations, then we have a hard time taking that serious. It is
always so easy and comfortable to do abstract thinking and then just
write an email, instead of doing the real work of seeing whether the
folks that actually implemented this stuff have gotten it wrong, too,
whereas a bunch of those implementers actually sit on the working
group.

Any XForms example that runs in more than one implementation,
no matter how simple, is of great value to the working group and
the XForms community. Reporting typos is nice, but doesn't
significantly improve the situation. Reporting errors without backing
them thru an isolated example that demonstrates the incorrect behaviour
in at least more than one implementation is simply dangerous, because
it might lead the working group to do a change that breaks something
else unexpectedly and forces the implementers to invest extra time
potentially for nothing and perhaps creating even more ambiguity.

The final, very last and only thing for all of us to do is to see where the
CR implementations differ from each other. In other words, to see
which parts of the spec *implementers* have interpreted differently.
Seeing which parts implementers actually have interpreted the same
way helps too of course, which means that those parts will remain
unchanged.

FormsPlayer, Novell XForms Explorer and X-Smiles are the
pieces of software you should download and install. Start writing
simple XForms and/or take the various XForms demos offered
in each of those implementations, change them and try to make them
work in the other implementations. If something doesn't work but
you're not sure whether it is a bug in the implementation or an
ambiguity in the XForms spec, try contacting the developers behind
the respective implementation first.

If you succeeded by writing an XForm, not matter how simple
or stupid, that works in more than one implementation, please
put it somewhere on the web and send a message to this list with
a pointer. If you have no space on the web, contact me and/or any
of the implementers, who are all glad to host more examples.

The working group will then take you very serious. Whenever you
post something about XForms in the future on this list or somewhere
else, the working group will listen carefully because we know that
you know what you're talking about and also, more important, that
you can actually do what you talk about.

If you find a real problem and you're sure it's not just a bug or
missing feature in the implementation, then isolate the problem,
put the example showing the problem on the web, ideally
reference the chapter in the spec where this functionality is described
and list the implementations you've checked this against. Report
this not on this list, but on mailto:www-forms-editor@w3.org.

If you ring the alarm bell, without ever having shown that you are
able of writing real XForms and at least have tried to make
it work in more than one XForms implementation, the working
group will still try to read your comment, but may decide to not
respond nor do any changes since we must assume the likelyhood
of you simply not getting XForms. Again, the spec is for
implementers, not authors. If you don't fully understand XForms
from reading the spec, this is not a problem with the spec, this is
what books are for and the various demos and tutorials offered by
the implementers, educational websites and lists like this one,
where asking questions about XForms is indeed what this list is also
for, which is something slightly different than ringing alarm bells.

Since we have more than a dozen implementations and three CR
implementations just two weeks after going to CR, please don't
even try to argue that the spec cannot be understood by its intended
audience (or is even fundamentally flawed) without backing your
argumentation with real evidence by showing us the example
isolating the problem and resulting in an unexpected behaviour in
more than one implementation.

I would like to apologize if you think my message is rude or impolite
and simply would like to point out that the reason why XForms is in
such good shape these days is not just because of all the things the
working group decided to do to make XForms happen, but also
because of all the things the working group decided to not do.

I'm encouraging everyone to take the time to write XForms and am
emphasizing the extreme realness of XForms both in terms of the
specification and its implementations and thus am not only showing an
easy way for everyone to get the full attention of the community and
working group instantly, but am also pointing out that your time and
energy used in the right way can now significantly make a difference
for the future of web forms by helping us find out where the
spec is being interpreted differently in the various implementations
and where not and avoiding fragmentation before it even happens
and therefore allowing interoperability.

Thank you,

- Sebastian
Received on Monday, 25 November 2002 23:45:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:21:54 GMT