Forms Task Force members (roll call and call to action), Fw: Architectural Consistency - What does it mean?

I think that Mark B, Nick and Sebastian are on the Forms task force.
We now have some concrete ideas that can be used to develop *some* kind of 
reasonable output from the task force.

I also received the following message (part of a larger message in 
www-archive) from a co-chair of the HTML WG (Dan C.):

(1) I think the line between syntax and architecture is
blurry at best, and I don't consider it out of order
to discuss specific syntax proposals. I'm not sure
that's the main objective of the task force, but
I can imagine cases where it's helpful.

(2) While many have observed that the current task force
organization hasn't produced all that much, I'd like
to give it a try for a at least a few more weeks.

Now is the time for the three of you to become active on this TF.  Please 
let me know *whether or not* you can do this.

Thank you,
John M. Boyer, Ph.D.
Senior Technical Staff Member
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
Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw


----- Forwarded by John Boyer/CanWest/IBM on 04/03/2008 12:55 PM -----

Maciej Stachowiak <mjs@apple.com> 
Sent by: public-forms-tf-request@w3.org
04/02/2008 09:18 PM

To
public-forms-tf@w3.org
cc

Subject
Architectural Consistency - What does it mean?








In the interests of making a positive contribution to the Task Force:

"Architectural Consistency" is a pretty broad term. One thing we 
should decide as a Task Force is what sense we intend it in.

Here are some possible ways of interpreting "architectural 
consistency" between multiple forms technologies:

1) Both are consistent with the Web architecture as a whole (in other 
words, URIs for addressing, documents described as markup, REST 
architecture model, etc).

2) Both may be used together on the same Web site without conflict.

3) Both may be used together in the same Web document without conflict 
(for example, through use of XML namespaces to disambiguate).

4) Both are reasonably aligned in their capabilities where they 
overlap, without gratuitous differences.

5) One may be implemented in terms of the other through a prior server 
side translation (this would be a scenario such as "author in XForms, 
translate to HTML Forms for client-side deployment").

6) One may be implemented in terms of the other through client-side 
script-based support (for example, XForms-like markup is sent to the 
client along with a script that translates the mechanisms to HTML 
Forms and implements the processing model).

7) Both must be describable in terms of a single server-side 
processing model.

8) Both must be describable in terms of a single client-side 
processing model.


I would argue that 1-7 are all reasonable expectations for 
architectural consistency. As an example, SVG and HTML would satisfy 
criteria 1-3 and 5-7, and 4 is debatable (there is some overlap in 
areas with differences but it is in dispute whether this is necessary 
or not, and the groups are working on closer alignment).

I would argue that #8 is too strong a requirement. For example, CSS 
and SVG have completely different models for layout. But because there 
are defined ways to interoperate, it is not generally argued that this 
makes them architecturally inconsistent. Similarly, http and ftp are 
completely different protocols from the client's perspective. But 
shared URI addressing and the request-response model bring them into 
an architecturally consistent whole.


Any thoughts from other Forms TF members? Are there other criteria 
that you would see as part of "architectural consistency"? Mine are 
all pretty general to the Web and not very specific to Forms.

Regards,
Maciej