Re: Forms Task Force Charter Requirement

Hi Maciej,

You're not sure because you're not sure where the compromise is because 
you are stridently opposed to any form of compromise.
Your language about anything you want to ignore being non-binding speaks 
Again, it looks like the W3C is bending all its rules to try and 
accommodate a wider community involvement only to have someone attempting 
to use the most rigidity and inflexibility available to quash the best 
intentions of the people who worked so hard to formulate those charters.
You really need to take a chill pill, find a dictionary and look up what 
"working together" means.
I'm really not going to keep servicing your inability to understand a 
world larger than your own.

John M. Boyer, Ph.D.
STSM: Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab


Maciej Stachowiak <> 
Sent by:
05/03/2007 02:22 PM

John Boyer/CanWest/IBM@IBMCA
" WG" <>
Re: Forms Task Force Charter Requirement

On May 3, 2007, at 1:47 PM, John Boyer wrote:

> Maciej,
> It sounds like you want to read just enough words to substantiate 
> your own point of view to the exclusion of any possibility for 
> compromise and in spite of any other reasonable interpretation of 
> the words.

I'm not sure what there is to compromise on - the HTML WG charter 
requirement on this seems pretty clear to me.

> The forms group seems to be bending over backwards in compromise, 
> such as saying "sure if you want to put those data model attributes 
> right into the presentation layer, go ahead, as long as there is at 
> least a clear and easy path to migrate up to greater sophistication 
> without having to throw out the form asset and start over..."
> Sure would be nice if, in kind, you could accept the fact that the 
> forms problem became a big issue and so the main author of the 
> charters wrote both together and fully expressed what needed to 
> happen with them.
> The HTML WG charter says that "The HTML WG and the Forms Working 
> Group will work together..." on something.  Are you telling me that 
> you find it unreasonable to actually go to the forms WG charter and 
> read its mission and its first paragraph to find out about this 
> "work together" thing?

The HTML WG charter says what we are supposed to work together on. 
And the HTML WG charter is binding on the HTML WG and the Forms WG 
charter isn't. Per the W3C Process, one working group's charter can't 
be binding on another group. So yes, I think it is reasonable to read 
the HTML WG charter to find out what it means, and ignore 
contradictory claims in other charters.

> The mission says " the forms WG is to develop specifications to 
> cover forms on the web.  Is that not plain?
> The last sentence of that first paragraph says "Documents using the 
> tag soup serialziation of the new HTML are expected to be converted 
> to the *equivalent XML serialization*".

This is all language from the Forms WG charter, right? I don't see 
how it can be in any way binding on the HTML WG.

> The vision document published with the two charters works even 
> harder to make this clear: "The charter calls for two equivalent 
> serialization to be developed, corresponding to a single DOM".  Dan 
> quotes from this document in 
> public-html/2007May/0280.html

If the vision document contradicts what the HTML WG charter says, 
then I think we have to ignore it per the W3C Process. The Process 
Document does not allow the charter to be altered by a document 
separate from the charter; we'd have to go through a rechartering 
process. Furthermore, this Vision Document did not go through the 
same Advisory Committee review as the charters themselves, giving W3C 
Members no meaningful opportunity to give feedback, so considering it 
as part of the charter would also violate the W3C Process.

Since your Formal Objection is based on what you call technical 
process issues, I believe referring to the W3C Process is the right 
way to determine its merits.

By the way, your quote drops some context on your quote: "Instead, 
the charter calls for two equivalent serializations to be developed 
**by the HTML WG**, corresponding to a single DOM (or infoset, though 
tag soup cannot be considered to have an infoset currently, while it 
can have a DOM)."

Emphasis added by me. Dan Connolly also removed the words "by the 
HTML WG" from his quote of the vision document. I'm not sure why he 
did that.

> How much plainer do we have to get that we are to build one tag set?

I don't see anything in the HTML WG charter that calls for building 
one tag set, in fact, it seems to state the contrary (that HTML Forms 
and XForms Transitional will be architecturally consistent but 
separate). The part of the nonbinding Vision Document that you cited 
seems to refer to the HTML WG creating both HTML and XML 
serializations of HTML, and not to anything related to XForms.

> Basically, the language about 'architectural consistency' is 
> supposed to allow the flexibility needed for variations that will 
> undoubtedly arise because of tag soup quirks and because of 
> interactions between form things and html-specific things that the 
> forward-thinking charter author would be reasonable to assume might 
> occur.  A good example would be the desire for html to define its 
> own UI controls, which is fine because it does not significantly 
> alter the UI binding architecture.

My interpretation of "architectural consistency" between two languages:

- Two languages that don't interfere with each other if both 
implemented, and that follow a particular common set of architectural 

Your interpretation appears to be something like:

- One tag set that has two serializations that correspond to a single 
DOM, but with variations between two languages, for example, 
different sets of UI controls.

I think your interpretation stretches the actual words of the charter 
a great deal, and furthermore is not even consistent with itself -- 
if the two languages vary, then by definition they are not one tag 
set and don't correspond to a single DOM. I suggest that the Working 
Group follow my interpretation.


Received on Thursday, 3 May 2007 23:19:30 UTC