W3C home > Mailing lists > Public > public-forms@w3.org > April 2009

Re: question: handling extremely heterogenous XSDs with XForms

From: Mark Birbeck <mark.birbeck@webbackplane.com>
Date: Tue, 28 Apr 2009 17:56:39 +0100
Message-ID: <ed77aa9f0904280956q1a488768ja884376cb50fb921@mail.gmail.com>
To: Joern Turner <joern.turner@googlemail.com>
Cc: "public-forms@w3.org" <public-forms@w3.org>
Hi Joern,

This is indeed a common problem.

I agree with everything you suggest, and the only thing that I would
do differently is that instead of creating a new action, I would just
use the existing load action, with the @show attribute borrowed from
XLink to describe how to use the data (@show="embed" would place it
into the document) and @target to indicate where.

I describe this in an old blog post:


We'll be adding this feature to Ubiquity XForms, once we've got past
the 1.1 work we're doing currently, so let us know if you decide to
implement it as well, or if you have some further suggestions.



On Tue, Apr 28, 2009 at 4:22 PM, Joern Turner
<joern.turner@googlemail.com> wrote:
> Dear group,
> we got a use case and we wonder how to handle this with XForms:
> we got a extremely complicated XSD and want to generate XForms to
> handle data entry and manipulation. So far so good. Now it happens
> that one structure we generate a XForms for allows a huge number of
> different sub-structures (several hundreds) each with it's own child
> elements/attributes and types. These don't need to be present in the
> data we load and it can't be foreseen which ones a user would like to
> add.
> There's no problem with the instance as we can use insert/@origin to
> choose the relevant piece of xml from a template instance but the
> problem (or inefficiency) arises with the UI:
> one solution that comes to mind is a big switch/case where each case
> models one of the sub-structures. However this would bloat the form a
> lot and force a XForms processor to take the burden of parsing and
> initializing the switch even if most of the cases are potentially
> never used.
> Thinking about this we got the idea that maybe a new action like
> 'insertUI' would make sense that allows to do just the same as insert
> does for the instance - to select a piece of UI markup from an
> instance and to insert it into the running UI. Of course some details
> like insertion point etc. have to clarified but i hope i made the
> problem clear.
> Has anyone come across a similar problem already? Happy about any
> suggestions or discussions regarding this (btw, i've looked into
> 'Future Features' and didn't find anything pointing in that
> direction).
> Joern Turner

Mark Birbeck, webBackplane



webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)
Received on Tuesday, 28 April 2009 16:57:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:00 UTC