Re: Decision Point on XForms 1.2

Hi Uli,

I am glad that yourself and some others (e.g. Charlie, MarkB) have 
expressed support for reducing scope of 1.2.  I am hoping to hear from 
some more of our regulars (e.g. Steven, Nick, Erik, Rafael).

Also, Uli, you raised a few adjustments to the proposal:

1) You said we should do default trigger.  Well, I would have said the 
same until we analyzed it at the face to face and found that current web 
app developers don't really have a good solution anyway.  As such, it 
seems like the behavior we describe in 1.1 for DOMActivate on input should 
suffice in the short run.  Frankly, the thing that makes me want to back 
off from it is the amount of intelligence it seems we would have to add 
just to get to the long form of what default trigger is trying to 
streamline.  As a result, it isn't streamlining of existing functionality 
really.

2) You said we need to think carefully about the model-driven switch.  I 
hope this paragraph will convince you that I for one have given it a lot 
of thought.  I think we ended up with something short and simple, add a 
child element of switch called "using" that has a single node binding. 
This is consistent with the approach taken for the upload element, and it 
does get at the feature.    It is important because right now people who 
want to do UI switching are pretty much forced not to use switch in 
certain cases.  Those cases arise in multi-session apps, including those 
that might occur in apps that would use src on model :-) as well as 
document-based XForms.  I think we need it soon because I am working on an 
initiative this year related to ODF to see if we can get an upcoming 
version of that standard to adopt the XForms UI layer.  This is the last 
major issue for ODF-like applications of XForms relative to typical (i.e. 
ephemeral) XHTML-like applications of XForms.

3) You said we should do src on model.  I think you're right that it is 
inline with the 1.2 theme.  I'd like to see both src and resource, as 
we've done for instance-- and for the same reasons.  But either way it is 
an easy thing to do that does not seem to have the kind of processing 
model reverberations that, say, default trigger has.  So +1 from me on 
that.

4) You suggested simplifying the theme for 1.2 to just "Streamlining Web 
Applications".  I had thought of this first, and I could live with it.  It 
seems to have two downsides, though.  First, it seems to imply that prior 
versions of XForms did not make it easier to make web applications.  I 
think XForms today makes it easier to make web applications, if you know 
XForms.  What we'd like is to have a theme that says we are making it 
easier for you (the web app developer, I mean) to know XForms.  Second, 
there will always be detractors who will claim that no matter what we do 
we aren't streamlining web apps. The theme I put down avoids this 
political hot potato because it only says something about doing web apps 
in XForms, not web apps in general.   Given that reasoning, do you still 
prefer "Streamlining Web Applications"?

Cheers,
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





Ulrich Nicolas Lissé <unl@dreamlab.net> 
02/15/2008 11:38 AM

To
John Boyer/CanWest/IBM@IBMCA
cc
"Forms WG (new)" <public-forms@w3.org>
Subject
Re: Decision Point on XForms 1.2






John Boyer wrote:
> 
> Further to our telecon discussion about how to decide what's in or out 
> of XForms 1.2, there is a decision to be made here.
> 
> Right now, I think XForms 1.2 is too big compared to what was really 
> mandated by our charter.  This is one reason I put all remaining 
> "possible 1.2 or high 2.0 features" into 2.0.  But it doesn't seem like 
> that goes far enough.  I have a proposal below to cut scope for 1.2, but 

> first let's review what's currently listed.

Agreed. Even when starting to discuss model driven switch I got the 
feeling that we make things more complicated instead of easier. The 
current feature list for XForms 1.2 is rather bloated. I fear we would 
fail to deliver a spec that matches the original intent.

> 
> The features currently listed for 1.2 in the wiki
> 
> 1) ease-of-authoring patterns that are consistent with the expectations 
> set forth in our charter.  As a side note, we have *lots* of other ease 
> of authoring ideas, some are listed in 2.0 (like) AVTs and some have 
> crept up into 1.2 (like the repeat pattern).   But none of these go into 

> the bucket we are calling "ease of authoring" patterns because this 
> bucket is targeted at the "transitional" XForms on-ramp concept in our 
> charter for 1.2.  We need a better name than the one we have, but I 
> think it will be used to describe the overall release if the proposal 
> below is acceptable.
> 
> 2) User interface patterns.  A number of these seek to to capture what 
> people are doing with sets of our form controls that interact together 
> toward a common purpose. But some (like the wizard pattern), I think we 
> do not know well enough to codify something useful, and it will take too 

> long for 1.2 to figure it out.
> 
> 3) Composition patterns.  This has exciting stuff like nested models and 

> external models.  It also has stuff which could be looked at as being 
> other than composition, like the function definitions.
> 
> 4) Modularization. This work seems inevitable in order to do the 
> "simplification"/"transitional"/"on-ramp" work.
> 
> PROPOSAL: I propose that we drop the 'patterns' theme for XForms 1.2 and 

> instead focus on the core charter mandate.  I don't have a great name 
> for it yet, and I could use some help in this area.  But it's something 
> more like "XForms 1.2: Streamlined for Web Application Authors" .
> 

Yes, we should drop the patterns theme. As expressed at the FtF I feel a 
bit uncomfortable about this language. The term pattern always causes me 
to think of Design Patterns.

Regarding the new theme: What about shortening it to "XForms 1.2: 
Streamlining Web Applications"?

> Details:
> 
> i) I don't think we need three subthemes.
> 

+1

> ii) I think everything in our current "ease-of-authoring" bucket fits 
> into this new theme.
> 

+1

> iii) I think we have to do the switch/using construct because it is a 
> bug fix to the language, and we still need to do some of those.  But the 

> other "UI patterns" should be pushed off to 2.0 or later.
> 

Well, I think the switch/using construct has to be discussed a little 
further. And I think we should include "Default trigger" in 1.2. The 
other UI patterns should be deferred.

> iv) I think that the "custom XPath functions" fits this theme, in part 
> because the XPath function implementations could be provided by 
> Javascript.  But otherwise, the composition patterns really need to be 
> deferred to 2.0 (as much as it pains me to say that).
> 

+1 except for dropping external models. I would like to see model/@src 
in 1.2.

> v) We really need to modularize what we have so that it can be made 
> incrementally available to authors.  It fits the theme perfectly and 
> will streamline our ability to add more to XForms in the future.
> 

+INF :)

Regards,
Uli.


> Please consider this carefully and provide your feedback as soon as 
> possible, esp. those who sent regrets for next week's call.  We need 
> your feedback this week if at all possible.
> 
> Thanks,
> 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
> 

-- 
Ulrich Nicolas Lissé