W3C home > Mailing lists > Public > www-forms@w3.org > August 2006

Re: Can toggle@case or case@selected be calculated?

From: Ulrich Nicolas Lissť <u.n.l@gmx.net>
Date: Sat, 19 Aug 2006 00:41:34 +0200
Message-ID: <44E6421E.1@gmx.net>
To: "T.V Raman" <raman@google.com>
CC: boyerj@ca.ibm.com, www-forms@w3.org

Yes, I'd prefer to use AVTs rather than to introduce new markup which 
tends to bloat.

I even don't see a Pandora's box of processing questions open as John 
stated: It should be clearly stated when these AVTs are evaluated and in 
which context (like it is for any other XPath expression in XForms).

AVTs occurring in non-XForms-markup are not the XForms processor's cup 
of tea. The latter might be dissatisfying to form authors attempting to 
use AVTs in XHTML markup but they can't use XPath expressions there too. 
So this is no point against introducing AVTs to XForms in my eyes.

Regards,
Uli.

T.V Raman wrote:
> 
> I've said this too many times in the last few years, so once more
> wont hurt :-)
> 
> Re: dynamic attributes -- they're a good thing. I believe the way
> they should be introduced into technologies like XForms and XHTML
> is via Attribute Value Templates e.g. <foo bar="{expression}"/>
> -- rather than on a case-by-case basis into a given XML
> vocabulary.
> 
> 
> Ulrich Nicolas Lissť writes:
>  > 
>  > John,
>  > 
>  > I just thought of having dynamic attribute(s) on xf:dispatch too. I 
>  > think this issue already popped up on the list but frankly speaking I'm 
>  > just to lazy to search the archives right now.
>  > 
>  > However, I think it would be most useful having either @name or @target 
>  > or both attributes being computed by XPath expressions. I think @target 
>  > is the more interesting case, just like for xf:setfocus/@control and 
>  > xf:toggle/@case.
>  > 
>  > Best,
>  > Uli.
>  > 
>  > John Boyer wrote:
>  > > 
>  > > Hi Ulrich,
>  > > 
>  > > Could you send me a quick note, please, to tell me a little more about 
>  > > what you want to see for xf:dispatch?
>  > > 
>  > > However, I did understand the part about precedence, and yes it will be 
>  > > included as we faced the same precedence rule issue when we added 
>  > > resource as a child of submission.
>  > > 
>  > > Cheers,
>  > > John M. Boyer, Ph.D.
>  > > Senior Product Architect/Research Scientist
>  > > Co-Chair, W3C XForms Working Group
>  > > Workplace, Portal and Collaboration Software
>  > > IBM Victoria Software Lab
>  > > E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/
>  > > 
>  > > Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
>  > > 
>  > > 
>  > > 
>  > > 
>  > > *Ulrich Nicolas Lissť <u.n.l@gmx.net>*
>  > > Sent by: www-forms-request@w3.org
>  > > 
>  > > 08/18/2006 04:25 AM
>  > > 
>  > > 	
>  > > To
>  > > 	John Boyer/CanWest/IBM@IBMCA
>  > > cc
>  > > 	Erik Bruchez <ebruchez@orbeon.com>, www-forms@w3.org
>  > > Subject
>  > > 	Re: Can toggle@case or case@selected be calculated?
>  > > 
>  > > 
>  > > 	
>  > > 
>  > > 
>  > > 
>  > > 
>  > > 
>  > > 
>  > > John,
>  > > 
>  > > please include <xf:dispatch/> too. And - just for completeness - don't
>  > > forget the precedence stuff (bindings ruling out static attributes ?).
>  > > 
>  > > However, I don't like the sub-markup approach that much. I'd prefer a
>  > > @value attribute.
>  > > 
>  > > Regards,
>  > > Uli.
>  > > 
>  > > John Boyer wrote:
>  > >  >
>  > >  > I generally like the type of approach Eric describes in which we use a
>  > >  > sub-element with a value attribute, where the subelement takes the same
>  > >  > name as the attribute it controls.
>  > >  >
>  > >  > I like it better than ATVs because ATVs open a Pandora's box of
>  > >  > processing questions, whereas the subelement/@value idea allows us to
>  > >  > add functionality precisely where it's needed in a way that is easy for
>  > >  > form authors to grasp and for design environments to recognize.
>  > >  >
>  > >  > In this case, though, my proposal on today's telecon was to do a
>  > >  > spec-ready version of the more specific solution I posted earlier to
>  > >  > this list, which was to make available a subelement/@value solution for
>  > >  > setting the case of a toggle action and the control of a setfocus, e.g.
>  > >  >
>  > >  > <toggle>
>  > >  >    <case value="concat('case-', some/node)"/>
>  > >  > </toggle>
>  > >  >
>  > >  > <setfocus>
>  > >  >    <control value="concat('control-', some/node)"/>
>  > >  > </setfocus>
>  > >  >
>  > >  > Based on having received the action item to do so on today's telecon, I
>  > >  > will be making that spec-ready text available to the WG shortly, but the
>  > >  > solution is so easy that I would not be surprised to see implementer
>  > >  > feedback even before I finish the formal spec work!  Partly because
>  > >  > XForms just needs to be able to do this (whereas there's a whole
>  > >  > Pandora's box of issues that this solution happily avoids).
>  > >  >
>  > >  > Best regards,
>  > >  > John M. Boyer, Ph.D.
>  > >  > Senior Product Architect/Research Scientist
>  > >  > Co-Chair, W3C XForms Working Group
>  > >  > Workplace, Portal and Collaboration Software
>  > >  > IBM Victoria Software Lab
>  > >  > E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/
>  > >  >
>  > >  > Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
>  > >  >
>  > >  >
>  > >  >
>  > >  >
>  > >  > *Erik Bruchez <ebruchez@orbeon.com>*
>  > >  > Sent by: www-forms-request@w3.org
>  > >  >
>  > >  > 08/16/2006 11:34 AM
>  > >  >
>  > >  >                  
>  > >  > To
>  > >  >                  www-forms@w3.org
>  > >  > cc
>  > >  >                  
>  > >  > Subject
>  > >  >                  Re: Can toggle@case or case@selected be calculated?
>  > >  >
>  > >  >
>  > >  >                  
>  > >  >
>  > >  >
>  > >  >
>  > >  >
>  > >  >
>  > >  >
>  > >  > Klotz, Leigh wrote:
>  > >  >  > Two issues come to mind:
>  > >  >  > 1. Currently @selected it's defined as an xsd:boolean (an enumeration
>  > >  > of the strings "true", "false", "1", and "0".
>  > >  >  > Unfortunately, "true" isn't an XPath expression that evaluates to
>  > >  > "true"; that would have to be "true()", so there's not the smooth
>  > >  > upgrade path that it seems like there might be.
>  > >  >
>  > >  > One possible direction, syntactically, would be to use a nested element,
>  > >  > as we may do for xforms:submission in 1.1. E.g.:
>  > >  >
>  > >  > <xforms:case>
>  > >  >   <xforms:selected value="instance('my-instance')/my-value = 3"/>
>  > >  >   ...
>  > >  >
>  > >  > or something like this. Ideally I would prefer attribute value templates
>  > >  >  (post-1.1)but as you point out there is a discrepancy between 'true'
>  > >  > and true().
>  > >  >
>  > >  > -Erik
>  > >  >
>  > >  > --
>  > >  > Orbeon - XForms Everywhere:
>  > >  > http://www.orbeon.com/blog/
>  > >  >
>  > >  >
>  > > 
>  > > 
>  > > -- 
>  > > Ulrich Nicolas Lissť
>  > > 
>  > > 
>  > > 
>  > 
>  > 
>  > -- 
>  > Ulrich Nicolas Lissť
>  > 
> 


-- 
Ulrich Nicolas Lissť
Received on Friday, 18 August 2006 22:49:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:06 GMT