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

question: handling extremely heterogenous XSDs with XForms

From: Joern Turner <joern.turner@googlemail.com>
Date: Tue, 28 Apr 2009 17:22:16 +0200
Message-ID: <67f00ca70904280822s6661afc2l34af2d0019aaf7ef@mail.gmail.com>
To: "public-forms@w3.org" <public-forms@w3.org>
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
Received on Tuesday, 28 April 2009 15:37:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 October 2013 22:06:50 UTC