Re: Decision Point on XForms 1.2

Hi John,

please see my comments inline.

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

I completely agree that default trigger is a hard nut to crack. And, 
yes, it is not streamlining of existing functionality but a new feature 
- just like model-driven switch etc. ;-)

I think default trigger would be a great gain from the author's 
perspective. But given the expected amount of work to be done in a tight 
schedule I'm not especially concerned about this. It's a nice-to-have 
feature to me.

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

I don't want to question the model-driven switch at all. I do see the 
desperate need for it and I appreciate all the energy you put into this. 
I just wanted to stress the point that the current proposal of realizing 
a model-driven switch with the switch/using construct is not really 
compelling to all WG members.

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

Great. It is really low-hanging fruit and should be done separately from 
nested models.

> 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"?
> 

I can live with the original proposal. But I think the usual suspects 
will claim that XForms 1.2 isn't streamlined for Web applications 
either. So any theme mentioning Web applications will cause the common 
hubbub.

Regards,
Uli.

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

-- 
Ulrich Nicolas Lissé

Received on Wednesday, 20 February 2008 11:59:41 UTC