Re: Decision Point on XForms 1.2

All,

Certainly the WG has my support for a reduced 1.2 scope, as I can't  
wait for the real good stuff in 2.0 ;-)

-Erik

On Feb 15, 2008, at 1:59 PM, John Boyer wrote:

>
> 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:
> >

--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/

Received on Friday, 15 February 2008 22:23:07 UTC