Re: XForms 1.2 and simplification versus XForms 2.0 triage

John, All,

I'm not sure what the best way is for answering to this e-mail. I decided 
to include answers to some specific points in-line and give some more 
global thoughts in front. 


Highest Priority 1.2 features  : I agree that those (or most see in-line 
comment) should be in XForms 1.2.

Possible 1.2 features :  see in-line comment

Possible 1.2 features (Suggest High Priority) : see in-line comments on 
decimal-string and sumproduct


Possible 1.2 features (Suggest Medium Priority) and (Suggest Low Priority)

We should consider if we want to keep all/some of these based on when we 
want to finish XForms 1.2 and how many people want to focus mainly on 
XForms 1.2 (and not so much on XForms 2.0).

I included my specific answers in-line: 

public-forms-request@w3.org wrote on 12/05/2007 09:50:05 PM:

> 
> Well, I'd like to further prime the pump of getting from the bottom 
> (things on the future features wiki) to the top (guiding principles,
> requirements) for 1.2 and 2.0. 
> 
> I remain convinced we need two documents, but otherwise agree with 
> Sebastian that any further increase in the number of net documents 
> we produce will simply bog us down in process land. 

I agree that we need two separate documents for XForms 1.2 and 2.0, but 
I'm also still convinced that we need to create for both those documents 
an requirements document (I'm volunteering of becoming a (co-)editor for 
the XForms 1.2 requirements document) I also think that having a 
requirements document will help us while processing LC-comments. And give 
us a better overview of what we want to accomplish with XForms 1.2 and 
XForms 2.0.


> 
> To generate discussion, I put an initial triage of features into the
> telecon agenda, and I think we should move forward with that, 
> recategorizing between 1.2 and 2.0 as needed or wanted by the group,
> and especially adding hierarchy to the list.  The parent nodes of 
> features will be the so-called guiding principles. 
> 
> One area that I partially missed in my triage were some of the wiki 
> elements under XForms simplification (go to the bottom).  I actually
> got most of them, I just thought someone moved the whole batch into 
> the "XForms Transitional" feature.  It now likes like I missed a few
> other listed features as well.  It turns out that my view of the 
> future features was hampered by the shoddy network service here at 
> the XML conference hotel combined with a crash of the W3C wiki server. 
> 
> Anyway, I would like to start with that XForms simplification list 
> because I think that *some* of the listed features are along the 
> lines of what we have long been talking about for simplification, 
> and which could be called "Simplify Glass-to-Data Forms Authoring". 
> Here's what I think falls into that category: 
> 
> Highest Priority 1.2 features 
> ----------------------------- 
> 1) Make model optional 
> 2) Add model item properties to UI controls (e.g. readonly, type and
> maybe calculate) 
> 3) Allow submission elements without model 
> 4) Allow instance elements without model (preferrably without 
> interfering with the implicit instance generated for certain UI 
controls) 
> 5) Add support for default values on UI controls without need of 
> instance element

I also think these are important features that will ease the authoring of 
forms 
(I'm not completely sure about the instance element, I think this is 
covered by point 5, point 5 doesn't covers web service calls but I think 
we need an action (or other method) to generate an implicit instance 
containing the SOAP envelope based on a WSDL)
 
> 
> There are three features listed under XForms simplification which I 
> think are not "Glass-to-Data Forms Authoring" and so they should be 
> considered separately.  At least one of them feels much more like a 
> 2.0 feature. 
> 
> Possible 1.2 features 
> --------------------- 
> 6) Simplified repeat authoring by codifying common things needed 
> when repeating (suggest medium priority)

This is a nice to have, but I personally think this is 2.0 feature, 
because it is going to be a lot of work to identify the common patterns 
and find an optimal way to abstract them in the language. I also think 
that this is big language change for a dot release (but not sure if this 
is a problem for a W3C spec)
 
> 7) Same model item property on same node, or perhaps just the 
> constraint MIP (suggest high priority)

Personally I would prefer putting this one in XForms 1.2, because I think 
it is an easy fix (not need for new language constructs, if we want this 
it is quite clear what should be changed).

And it solves the following problem that I hit numerous times: 
If you have conceptually two different sets of model item properties that 
apply to two different sets of nodes you can use two separate bind 
elements to express those model item properties. But when those two sets 
of nodes have nodes in common you can no longer use those two bind 
elements. To work around this limitation you have to create a third bind 
element with the combined model item properties and a node set that refers 
only the common nodes. You also have to adjust the node set expressions of 
the two bind element to have no nodes in common. This work around requires 
the duplication of the model item properties and more complex node set 
expressions, which is of course not desired for maintenance. 

> 
> Neither of these is "Glass-to-Data Forms Authoring", but are 
> instances of a more general concept of "Ease of authoring".  Still, 
> they don't feel like fundamental shifts. 
> 
> I would also suggest that perhaps the simplified repeat authoring is
> more likely to move from 1.2 to 2.0 because it is a bigger change to
> the tag set and the way we currently do repeats. 
> 
> Possible 2.0 features 
> --------------------- 
> 8) Add support for multiple expression languages. 
> 
> This one really feels like it is a more fundamental shift because it
> reverberates through the whole processing model and how you might 
> write pieces of the entire form.  Frankly, I would actually suggest 
> that this is *more general* than "Alignment with XPath 2.0", or 
> rather that XPath 2.0 alignment is a special case of this feature. 
> I think we will get this as part of the refactoring that would also 
> perhaps allow us to do JSON data with javascript referencing and 
calculations.

As previously stated I think that "Different users prefer different 
languages to write their queries and calculation expressions. XForms 1.1 
supports only XPath 1.0 for its query (to specify node sets and refer 
nodes), constraint and calculation language. Examples of languages that 
could be used as query, constraint and calculation languages are XPath 
2.0, javascript (for example using ECMAScript for XML)"

> 
> The rest of my triage sought to classify as 1.2 all features which 
> seemed to fall into the "Ease of authoring" category, either for all
> forms or for certain kinds of form applications.  Here they are with
> a rationale: 
> 
> Possible 1.2 features (Suggest High Priority) 
> --------------------------------------------- 
> 9) decimal-string() function - this is a hard requirement for 
> financial apps due to the insufficient precision of double numbers. 
> It rounds to a certain precision past the decimal point.  Note that 
> this cannot be done with "intelligent" UI controls in part because 
> it is the underlying data that is choking up server tier apps, 
> requiring either this fix or a fix on the middle tier, which as you 
> know directly contradicts the XForms value proposition.

I don't think we should do it on a version of XForms that is based on 
XPath 1.0, because it is automatically solved when we go to XPath 2.0 and 
and all calculations in XPath 1.0 are done in double-precision 64-bit 
format IEEE 754 
=> for me if XPath 2.0 is in XForms 2.0 (which I think is feasible) => 
decimal calculations, rounding, ... are in XForms 2.0 

> 
> 10) sumproduct() function - this is required for ease of authoring 
> simple purchase order apps.  Right now, one has to create extra data
> layer nodes to hold row products so that a sum can be computed. 

This one is a bit difficult I think, XForms 1.1 contains all the common 
aggregation functions (sum, avg, min,...) adding a sumproduct function to 
XForms 1.2 sounds a bit strange because why a function that first does a 
product of two arguments and then sum them all? What if I have a discount 
on each row in my form, then I can't use the sumproduct function anymore 
(I know that we can design it to have more then two XPath expressions to 
multiply, but I can find another use case which can't be solved by this 
function). Wouldn't it be better that we have an 'aggregate' function with 
which you can build your own custom aggregate functions? For example a 
function with two arguments with the first argument the node set to 
operate over, the second an XPath expression that is evaluated on each 
node and the result is put in a result set which you then can feed on 
another function (e.g.: sum).

It would even be better that we could define our own functions inside the 
form (or maybe external) like you can in xslt but this is going to be a 
bit to much I guess

> 
> 11) We should consider a better ability to both enclose and extract 
> attachments from instance data.  Four of the future "features" seem 
> necessary here: 
> 
> - We need to be able to say that the upload control can gzip 
> compress the upload content.  Also, although base64 or hexbinary 
> encoding is done based on the node's datatype, we need to be able to
> compel base 64 and/or hexbinary encoding *without* the schema 
> datatype assignment.  This is a "Glass-to-data" point. 
> 
> - Observe that we can upload content which may be compressed and 
> certainly is encoded, but we have no analogous ability to base 64 
> decode and decompress with file put submission.  We need to add 
> those two capabilities to file put submission 
> 
> - Once we can put the data out to disk in binary format, we need the
> analogous compress and encode on file get submission. 
> 
> - We have the ability to get and put files, so we need the ability 
> to present an Open or Save file browser dialog 
> 
> 12) Default trigger for form - this is ease of authoring and "Glass to 
Data" 
> 
> The wiki also contains this kludge (added by me but only in 
> desperation): Commit value on DOMActivate (enter) on input and 
> select1 and select selection=open.  I would advocate removing this 
> in favor of something direct. 
> 
> 13) Improvements to UI switching.  This is ease of authoring and 
> also fixes 1.x design shortcoming that causes people to do data-
> driven switching without using switch. 
> 
> - Model-driven switch with switch (case attr; xpath; result IDREF) 
> - Multi-case switch (case attr; xpath; result is IDREF list) 
> 
> 14) Simplified data manipulation actions 
> 
> - Actions for various kinds of insert and delete operations in Appendix 
B 
> - Create action that is like an insert+setvalue but requires no 
> origin template 
> 
> 15) mediatype on textarea to allow GUI edit of basic html (enriched 
> text editing) - this gives our authors an ability to enhance the 
> end-user experience for Web 2.0 applications. 
> 
> 16) Composable, componentized models; this is needed to simplify 
> development of larger XForms 
> 
> -  Allow src on model 
> - Allow model within model, where id on inner model is ignored and 
> all contained models can talk to each other 
> 
> 17) Allow access to web services that return xml as encoded text 
> - allow xmlparse() function, whose result could be used as the 
> origin of an insert 
> - allow xmlserialize() for analogous sending to such web services 
> 
> 
> Possible 1.2 features (Suggest Medium Priority) 
> ----------------------------------------------- 
> 
> 18) Better control over submission progress and cancellation 
> - Ability to cancel submission 
> -  Submission progress events 
> 
> 19) Action (?) with ability to ask if subtree is valid; needed for 
> better wizard support

I would prefer an XPath function see http://www.exforms.org/mips.html for 
more information.
 
> 
> 20) Put ref or context on action element (ease of authoring multiple
> action scripts relative to same node) 
> 
> 21) Let @value override single node binding on output (ease of 
> authoring an output that gets MIPs from ref node but calculates display 
value)
> 
> 22) Put @context everywhere (or at least repeat and likely group and 
switch) 
> 
> 23) Custom UI controls - describe ability to attach non-XForms UI 
> controls directly to model OR describe how to associate non XForms 
> controls with XForms controls 
> 
> 24) Aggregated controls that act like a single control 
> 
> 25) UI controls that can provide a subtree as opposed to a string 
> 
> 26) Tree control 
> 
> 27) Better DOM interface to expose only data manipulation actions 
> (fuller DOM interface appears in 2.0) 
> 
> 29) Better expression of default values 
> 
> 30) Wiki Markup for XForms (Creation of interactive content) 
>  I believe this is one of those "killer app" concept to allow more 
> sophisticated data collection in wikis 
> 
> 
> Possible 1.2 features (Suggest Low Priority) 
> -------------------------------------------- 
> 31) Action to cancel events, which can be conditionally run with @if 
> 
> 32) Add bind() function, only for XPaths in form controls and 
> actions.  Would we still need @bind? 
> 
> 33) Better control of external instance (e.g. @submission on instance) 
> 
> 34) Context info for user defined events 
> 
> 35) Create a construct for actions that iterates over a nodeset 
> 
> 36) Fix select1 so that it can allow multiple items with the same 
> value to be selected simultaneously as well as one that restricts to
> only one item that matches. 
> 
> 37) Submission some kind of better filtering than relevance that 
> affects only submission and not the UI 
> 
> 38) xforms-value-changed context info for node changed 
> 
> 39) Recoverable 'xforms-link-error' on instance src failure 
> 
> Possible 2.0 features (and beyond) 
> ---------------------------------- 
> 
> Align with XPath 2.0 
> Consolidated Recalculate and Revalidate 
> XPath Function access to MIPs 
> Multiple constraints 
> Improved HTTP authentication 
> Refactor modules of XForms 
> Refactor schema support (allow pluggable schema, e.g. schema 1.1, 
> schematron, relaxng) 
> Integrate with XML signatures 
> AVTs 
> Variables in XPath 
> XBL integration 
> User-defined model item properties 
> Dialogs 
> Close Form 
> Ability to indicate if something is wrong in non-selected case/non-
> relevant group 
> SCXML integration 
> Multiple step undo (e.g. undo to last state) 
> Form apps as components 
> Multiple simultaneous uploads 
> Generate and maintain data based on schema 
> multiple schemas targeting same namespace (e.g. allow inline schema 
> to augment external schema; similar to having the internal one 
> import the external one). 
> Drive UI (presentational) properties from data and calculates 
> A document() function 
> DOM interface that exposes all aspects of XForms to script 
> 
> 
> The final caveat here is that these are just my own opinions and 
> just a first pass triage that will hopefully stimulate discussion 
> about where to move various bits so we can begin to tackle 
> requirements *and* FPWD documents for XForms 1.2 and 2.0. 
> 
> Best regards, 
> 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

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

--------------------------------------------------

Inventive Designers' Email Disclaimer:

http://www.inventivedesigners.com/email-disclaimer