W3C home > Mailing lists > Public > www-forms@w3.org > February 2007

Re: Bindings, relevance and implied attributes

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Wed, 14 Feb 2007 13:07:37 +0000
Message-ID: <640dd5060702140507r2c5d7123q1ca967848e85e708@mail.gmail.com>
To: "Fennell, Philip" <philip.fennell@hp.com>
Cc: www-forms@w3.org

Hi Philip,

> Implied attributes would seem to be a nuisance in cases like this
> because if, in order to allow more conventional editing UIs, you
> actually have to populate and default those implied attributes in the
> instance data then having them implied is a waste of time. You might as
> well create your schema with all attributes defaulted and the form
> generator insert any attributes missing from the instance data to
> prevent you from having to clutter your GUI with 'Enable me' checkboxes
> (or triggers).
> As a more general question, when people are data modeling and form
> designing do people shun implied attributes because of the kind of
> problem I've described?

This is unfortunately the big gaping hole in XForms when running
complex forms that use schemas, and the problem is the same for
optional elements and attributes. But I'm not convinced that the
solution lies in XForms itself, and believe that it could probably be
defined as a set of extension functions.

The interesting thing is that you can get all of the necessary
information for what nodes can be added at some point in the structure
from the schemas themselves. All we need therefore, is to define a way
to make this information available to the form. This is something
we've looked at in the past with formsPlayer, but never completed, but
a recent project bought the requirement to the fore.

We've been working on a large number of forms for a customer in the
insurance industry, and the forms use the Origo schemas. These schemas
are quite complex--and rich--and for now we managed to avoid the issue
that you are referring to by simply providing the forms with initial
instance data that includes most of the permutations. That's ok for us
(as in x-port), because our role here is to author the forms; but it's
not so great for our customer because they have to do some
pre-processing to work out what instance data to pass in the form that
is delivered to formsPlayer! But a more advanced solution is easily
achievable, by providing some extension functions that allow a list of
'acceptable' nodes to be obtained at any point in the tree.

I don't think these functions should be part of XForms itself, but it
would be good if different implementations supported the same
functions. It might be possible to base the functions on the DOM3
Validation Spec [1].

Anyway, we'll be doing some work on this soon, so any use-cases that
people have for how they would see these functions being used would be
interesting to here.



[1] <http://www.w3.org/TR/DOM-Level-3-Val>

  Mark Birbeck, formsPlayer

  mark.birbeck@x-port.net | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.
Received on Wednesday, 14 February 2007 13:08:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:55 UTC