- From: John Boyer <boyerj@ca.ibm.com>
- Date: Sat, 10 May 2008 15:39:56 -0700
- To: Nick_Van_den_Bleeken@inventivegroup.com
- Cc: "public-forms " <public-forms@w3.org>
- Message-ID: <OF186C424C.683A8F54-ON88257445.00797688-88257445.007C81E6@ca.ibm.com>
Mostly goodness below. A few points to work out:
1) Why is the name attribute not supported? It seemed like that might be
a good way to have an ID for the implied model. On the other hand, you
could say that if somebody wants to refer to it, then they better express
the model to give it an ID. That would be OK with me, I am just curious
if there is a reason to not support use of name on form.
2) Arent' accept and accept-charset just shorthand for certain header
settings? If so, shouldn't those be supported by us, since we can just
add them to the meaning of the implied submission?
3) I think we need to do the nested model work. In an earlier email you
mentioned that you guys wanted to defer nested model for now, and the
writing below seems to reflect that. But here's what breaks:
>From below, you're saying that the form tag only implies a model if it
contains no expressed model. If it contains an expressed model, then the
form tag attributes can imply an extra submission within that model. So
far so good, but what happens to the implied instance and binds of the
streamlined markup within the form tag when one adds an expressed model?
To avoid doing nested model work, you could say that the first model still
gets the implied instance and the extra binds from the streamlined markup.
You would have to stipulate that the implied instance would not be the
first instance of the expressed model because then you would change the
behavior of the expressed model. Otherwise, it would work... as far as it
goes.
Now consider the reason why the streamlined XForms author may want to
express a model within a form tag. I think the typical reason is that the
streamlined XForms author will express a model in his form tag is to
consume a model that contains the machinery for a web service. So now
consider that the author wants to consume just two web services. I think
the markup will look something like this:
<form name="F" ...>
...
<model id="S1" src=".../serviceDefinition1.xfmodel"/>
<model id="S2" src=".../serviceDefinition2.xfmodel"/>
...
<!-- streamlined XForms markup -->
</form>
If we take the view that S1 and S2 are both nested within model F, then it
is easy to see how one could set up an xforms-submit-done listener on S1
or S2 and then copy data to model F.
If we take the view that the instance and binds implied by F are generated
within S1, then how do results from S2 ever get into the instance data
that is driving the user interface in F?
Attempting to answer this question is actually how I got to the conclusion
that S1 and S2 needed to be the same logical thing, unencumbered by side
effects of F but able to pull results from F (e.g. on xforms-submit) and
push results to F (e.g. on xforms-submit-done). From there, it was a
short hop to the idea that S1 and S2 would be nested within F and
therefore have access to F commensurate with that scope.
Hope this helps...
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
Nick_Van_den_Bleeken@inventivegroup.com
Sent by: public-forms-request@w3.org
05/09/2008 01:44 AM
To
"public-forms " <public-forms@w3.org>
cc
Subject
Form tag(s), implied model(s)and implied submission
All,
We were a bit under manned on the previous XForms call, but nevertheless
we decided to make a resolution to add the optional form container element
to the XForms language. I'm eager to write some spec ready text related to
"Form tag(s), implied model(s)and implied submission". But just want to be
sure that the people that couldn't attend the previous call are in line
with what I felt what the direction on the previous call was.
1) Add a form tag with :
- required action attribute : Maps to action attribute on a
submission
- optional method attribute : Maps to method on submission
- optional enctype attribute : Maps to serialization on submission
- We don't support the following attributes : accept, name, onsubmit,
onreset, accept-charset
2) Form element creates an implicit model if no model is present as a
child. The current model is changed to the first model child of model or
the implicit model if no model element was present as a child of the form
element
3) An implicit submission is added to the 'first' model (can be the
implied model) of the form element using the attributes on the form
element
4) Allow submission attributes on the send and submit elements, the local
attributes will override the attributes of the referenced submission. When
no submission is specified the implied submission will be used as a basis.
Regards,
Nick Van den Bleeken - Research & Development Manager
Inventive Designers
Phone: +32 - 3 - 8210170
Fax: +32 - 3 - 8210171
Email: Nick_Van_den_Bleeken@inventivegroup.com
[1]
http://www.w3.org/MarkUp/Forms/wiki/Allow_submission_elements_without_model_element
Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
Received on Saturday, 10 May 2008 22:40:43 UTC