Re: charter all set now?

Hi Chris,

First, thanks for considering and approving an amendment related to my 
second point about XForms traction.

Regarding the first point, I would respectfully assert that the comm team 
is not correct in their belief that the HTML WG charter wording is clear 
*to the HTML WG*. 

You have indicated that the points in our email are covered by the 
wording, which is good news, but it is not an opinion shared by those in 
the HTML WG who seem most interested in this issue.

Our request for further wording is based on the desire to make sure that 
the charters do end up communicating the same things to both working 
groups, a goal I am sure the comm. team shares.

The existing wording in the HTML WG spec only says that they need to work 
on HTML forms so that it has 'architectural consistency' with XForms 
transitional.  However, the meaning of architectural consistency is not 
given in the HTML WG charter.  Important hints on its meaning do appear in 
the Forms WG charter, but the HTML WG members have expressed that they are 
not bound by that wording.  The vision document makes it much clearer 
still that we should really end up with the same tag set modulo the 
strictness of XML grammar and features of XForms/XForms transitional that 
are not included in HTML forms.  But again, the HTML WG members have 
stated that they are not bound by the vision document.

The interpretation of the wording in the HTML charter that has been 
expressed to me by HTML WG members is that architectural consistency is to 
be considered in the broadest possible way, e.g. if XForms can repeat UI 
controls and Web Forms 2.0 can repeat UI controls, then both can repeat so 
that is "architecturally consistent". 

What we hope for instead is to have a syntax that can address the 
ease-of-authoring/implementing capabilities of WF2 in a way that makes it 
easy to understand how to consume or adopt more of the features of XForms 
incrementally as needed.  That's what transitional is supposed to be 
about.  Unfortunately, while the phrase "document authors can transition 
between them"  seems to mean the above to the Forms WG, it also means 
something completely different  to the HTML WG members.

The HTML WG members who have expressed opinions so far have read this to 
mean that a transition could be arbitrarily complex, mapping from two 
totally different tag sets.  While not being convenient at all for the 
authors to transition in this way, it is at least computationally feasible 
and so it is deemed "good enough for now".  The problem is that this view 
is too short-term in that it only works when one considers the limited set 
of features that are now under discussion for the HTML forms run-time 
processors to support.  This view does not allow for a smooth transition 
to the features that truly are needed to manage complexity as the size of 
the desired forms applications continues to grow.

As separate issues, then, it would help if

1) The sentence in the Forms WG charter which says 

"The Forms WG will work with the HTML WG to ensure that XForms 
Transitional processors will accept the HTML Forms developed by the HTML 
Working Group."

should just say 

"The Forms WG will work with the HTML WG to ensure that XForms 
Transitional processors will accept HTML Forms."

This at least avoids any sort of demotion of the Forms WG position in this 
joint venture relative to other content in our charter and in the vision 
document.

2) The "Forms Task Force" statement of dependency in the HTML WG charter 
does still seem to need clarification.  To give a better idea of what the 
wording needs to convey, here is the relevant content from the vision 
document:

"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). This ensures that decisions are not made which would 
preclude an XML serialization. It allows the two serializations to be 
inter-converted automatically. Having new language features, there is an 
incentive for content authors to use it; and having client-side 
implementations means that there is the possibility to really use it."

The current wording in the charter allows for alternate interpretations 
which are nowhere close to achieving the above effect and are therefore 
detrimental to the goal of providing a language that is simple to author 
and also simple to allow transition to the full features of XForms.

Perhaps it would be suitable to use the same wording as in the forms 
charter for expressing the relationship between HTML forms and XForms 
transitional:

"The HTML WG and the Forms Working Group will work together in a joint 
Task Force to develop HTML forms based on the tag set they jointly develop 
for XForms transitional.  XForms Transitional is syntactically a superset 
of classic HTML forms (and can thus process classic HTML forms) while 
retaining an underlying XForms processing architecture. It is a goal to 
have two equivalent serializations of an HTML form (non-XML and XForms 
transitional XML) that correspond to a single DOM or information set for 
the form. It is also a goal that this work will draw on the Web Forms 2 
work and be integrated into the XForms architecture (following design 
principles such as separation of presentation from content)." 

In conclusion, I hope it is clear that the Forms WG does not yet believe 
there is a common understanding about what the charters ask the two 
working groups to do regarding forms, and we hope that the above wording, 
or something like it, will help to produce a unified direction that will 
be of greatest benefit to the web community in the longer term.

Thanks,
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
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer





Chris Lilley <chris@w3.org> 
07/02/2007 09:48 AM
Please respond to
Chris Lilley <chris@w3.org>


To
John Boyer/CanWest/IBM@IBMCA
cc
public-forms@w3.org
Subject
Re: charter all set now?






On Wednesday, June 27, 2007, 8:44:10 PM, John wrote:

JB> There is only one diff-marked section that jumped out as really
JB> different from what the Forms WG otherwise understands as its
JB> mission, as expressed in charter mission statement. 
JB> 
JB> The mission statement seems to more accurately reflect our
JB> understanding, which is that it is the Forms WG mission to
JB> *develop* specifications that cover forms on the Web. 
JB> 
JB> Yet the description of the dependency between the Forms WG and the
JB> HTML WG says:
JB> 
JB> "The Forms WG will work with the HTML WG to ensure that XForms
JB> Transitional processors will accept the HTML Forms developed by
JB> the HTML Working Group."
JB> 
JB> The last part 'developed by the HTML working group' is
JB> problematic because it is the mission of the Forms WG to develop
JB> forms on the web, accounting via the joint task force for the
JB> forms requirements foreseen by the HTML WG.   
JB> 
JB> Despite this one case, I would say that my experience so far with
JB> the HTML WG suggests that their own opinions about how forms for
JB> the web are to be developed stems mostly from the fact that they
JB> do not feel bound by any statements expressed in a charter other
JB> than their own, despite the fact that you originally wrote them
JB> together.  They have expressed this directly, so this means that
JB> any statements of clarification would need to appear in both
JB> charters, not just the forms charter.

The html charter says

  The HTML WG and the Forms Working Group will work together in this
  Task Force to ensure that the new HTML forms and the new XForms
  Transitional have architectural consistency and that document
  authors can transition between them

so it seems that the existing charter already covers this. I discussed
this with the comm team and they said that the existing language
appeared to cover it.

JB> For example, there is a lot of confusion about the meaning of
JB> 'architectural consistency' and when I point to the key examples
JB> you give in the Forms WG charter, such as the expectation of
JB> "conversion from tag soup to *equivalent* XHTML serialization" or
JB> "following design principles such as separation of presentation
JB> from content", the response I get is that these are expressed in
JB> the forms charter so they are not binding on the HTML WG. 


JB> That sounds an awful lot like the HTML WG feels it is the HTML
JB> WG's mission to develop specifications that cover forms on the
JB> web, which of course undercuts the Forms WG mission and
JB> discourages motivation for Forms WG members to participate in any
JB> kind of joint task force (despite my best efforts to encourage 
otherwise).



JB> I think it would be fair to rephrase "but relatively little
JB> traction in the mainstream, browser sector" to something more
JB> accurate, such as "despite having only indirect support from
JB> features available in modern web browsers." 

We agree with that and have added similar wording (explicit mention of
plugins).


-- 
 Chris Lilley                    mailto:chris@w3.org
 Interaction Domain Leader
 Co-Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG