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: Thu, 15 Feb 2007 19:03:11 +0000
Message-ID: <640dd5060702151103l76745e2cp1419a704428e435f@mail.gmail.com>
To: "Klotz, Leigh" <Leigh.Klotz@xerox.com>
Cc: "Fennell, Philip" <philip.fennell@hp.com>, www-forms@w3.org

Leigh,

But the problem is really much more general. If a document can have:

  <a>
    <b />
    <c />
  </a>

but b and c are optional, what should we do? Currently we need b and c
to be sent to the form in the initial instance data, which is not
ideal for two reasons. First, the server needs to 'know' to include
optional values, and with very complex schemas, that's quite
difficult. And second, both nodes need to be sent to the server, even
if they are empty, since if either gets removed by the XForms
processor (due to relevance) it can't be added back again later
(round-tripping is messed up).

Whichever way you look at it, the server is having to do a lot of work
that it would be better for the client to do. There seem to me two
ways that the burden could be shifted to the client.

The first is that an instance that contains all possible nodes is
added to the form, and then a series of conditional inserts are
specified to copy one or other of these templates, if it is missing.
(This would use the XForms 1.1 @origin feature to copy nodes.) This is
of course just as difficult to manage as the 'server-side initial
instance' problem, since somehow you'd need to generate templates and
code that match the schemas.

The second solution is for the XForms processor itself to be able to
provide the form with information obtained from the schema, and so
have much more generic actions.

It's this latter solution that we are exploring.

Best regards,

Mark


On 15/02/07, Klotz, Leigh <Leigh.Klotz@xerox.com> wrote:
>
> Your XForms processor will probably follow the XML 1.0 Recommendation
> and process the DTD-declared default values when reading an external
> instance, so you probably don't need to merge yourself.  However, as
> XForms doesn't have any particular smarts about DTDs after that point,
> you're right, it won't be able to remove them if they have the default
> value.
>
> The best course I can suggest is a two-step
> (1) use a DTD to default the values
> (2) use an immediate post-submit step in the server side to remove the
> attribute values that retain their defaults.
>
> It does seem a bit ornery of SVG to have default values that act
> differently if they are specified as their default values, but there you
> go.
>
> Leigh.
>
> -----Original Message-----
> From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On
> Behalf Of Fennell, Philip
> Sent: Wednesday, February 14, 2007 5:33 AM
> To: www-forms@w3.org
> Subject: 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.
>
>
>
>


-- 
  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 Thursday, 15 February 2007 19:03:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:09 GMT