RE: Bindings, relevance and implied attributes

Mark,

Thank you for the feedback, its good to know that I'm not the only one
feeling this pain. ;-)

As my forms are machine generated, I have the option to merge the
missing attributes into the instance data so that all the bound controls
will be accessible. However, I'm still left with the problem that if I
didn't want the implied/optional (DTD/Schema) attributes, that I haven't
edited, in the updated source document I would have to find some way of
making them non-relevant so that they are removed from the instance data
when the form is submitted.

I suppose I could come up with a way of generating a form with a set of
actions (one for each implied attribute that has been defaulted)
attached to the submission button/event such that any of the implied
attributes who's value has not been changed (still the default value)
will be set as non-relevant and therefore be removed from the instance
data. I'd have to read-up about actions etc to see how I'd do that, but
do you think that this ideas is, at first glance, a feasable option?


Regards

Philip Fennell



-----Original Message-----
From: mark.birbeck@gmail.com [mailto:mark.birbeck@gmail.com] On Behalf
Of Mark Birbeck
Sent: 14 February 2007 13:08
To: Fennell, Philip
Cc: www-forms@w3.org
Subject: Re: Bindings, relevance and implied attributes

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.

Regards,

Mark

[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:33:21 UTC