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

RE: XForms schema: mustUnderstand and extension

From: T.V Raman <raman@google.com>
Date: Fri, 25 Aug 2006 08:06:49 -0700
Message-ID: <17647.4617.426700.192803@retriever.corp.google.com>
To: monterro2004@tiscali.co.uk
Cc: mark.birbeck@x-port.net, kratky@us.ibm.com, www-forms@w3.org

JSON is a fine S-Expression representation --- and in some
respects a better S-Expression for pure data than XML.

Another interesting XForms extension that we should look at is
the ability to bind to JSON data for instance values --- Given
that XForms has a clean Data vs Interaction separation, this
should actually be quite easy to do 

Francisco Monteiro writes:
 > The way facileXForms implements extensions is via a "bridge", since most of
 > our extensions are either Dojo or Yahoo (YUI) composite widgets, the bridge
 > acts as the controller to the view and model. The bridge has the same logic
 > as a group element and then uses publish/subscribe paradigm for all its
 > children . This way any framework can easily be "plugged" in.
 > Also we did this, because we use JSON as our data interchange. Every one
 > wants JSON today.
 > <my:controller ref=".." id="controller1">
 > <dojo:widgets
 > <yui:widgets
 > <xf:action all events as per group element
 > facileXForms from an Xforms perspective is only interested in the model, our
 > Xforms with XML Events (client end ) is the controller.
 > When we have finished our implementation we will support fully Windows
 > Workflow Foundation concepts (client and server end).The Xforms model markup
 > is far simpler then the foundations XAML, we can transcribe between the two.
 > So the logic goes we will be supporting
 > 1] Sequential Workflows
 > 2] Machine state workflow with dynamic updates to single instance of
 > workflow
 > 3] Data driven workflows
 > We should all thank Microsoft for bringing Workflow concepts to the masses.
 > See some of the many example I have sent to the group
 > Francisco
 > -----Original Message-----
 > From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On Behalf
 > Of Mark Birbeck
 > Sent: 24 August 2006 13:11
 > To: Jan J Kratky
 > Cc: www-forms@w3.org; w3c-forms@w3.org
 > Subject: Re: XForms schema: mustUnderstand and extension
 > Hi Jan,
 > > Does anyone disagree that extension
 > > should be permitted as a child of *any* XForms element? What about as 
 > > a child of elements (i.e. setvalue) whose content models currently do 
 > > not permit other elements as children? Are multiple extension elements 
 > > permitted as a child of the same XForms element? Can the extension 
 > > element appear anywhere in the sequence of child elements?
 > It would be interesting to see how people have implemented xf:extension, in
 > order to see what the options are.
 > What we've done in formsPlayer is to treat xf:extension just like an
 > xf:instance that was 'local' to the parent element. At run-time we parse the
 > contents of the xf:extension, and then create an attribute called
 > 'extension' on the parent node, which contains a DOM with the contents of
 > the xf:extension.
 > This is then available to any script, in particular to our XBL widgets,
 > which makes it a very convenient way for an author to provide extra data for
 > run-time use.
 > Taking this approach does mean for us though, that it would be more logical
 > if only one xf:extension was allowed per element. But given that
 > xf:extension wasn't defined very clearly in the first place, I'm not at all
 > saying that our approach is supported by the spec--simply that this is the
 > approach we took, to try to make something useful from xf:extension.
 > I'd be interested to hear how others have made use of xf:extension.
 > Regards,
 > Mark
 > --
 > Mark Birbeck
 > CEO
 > x-port.net Ltd.
 > e: Mark.Birbeck@x-port.net
 > t: +44 (0) 20 7689 9232
 > w: http://www.formsPlayer.com/
 > b: http://internet-apps.blogspot.com/
 > Download our XForms processor from
 > http://www.formsPlayer.com/

Best Regards,

Title:  Research Scientist      
Email:  raman@google.com
WWW:    http://emacspeak.sf.net/raman/
GTalk:  raman@google.com, tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
Received on Friday, 25 August 2006 15:08:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:18 UTC