RE: Bindings, relevance and implied attributes

Mark,
I'm all for prototyping new solutions for the general problem and don't
want to cut that off at all, but if you have to ship today and the
problem is attributes only, a DTD to add them in the client and an XSLT
to remove them on the server will do the trick with the least custom
code.  Maybe talk to the Schema folks again -- they're adding new
features as we speak.
Leigh.
-----Original Message-----
From: mark.birbeck@gmail.com [mailto:mark.birbeck@gmail.com] On Behalf
Of Mark Birbeck
Sent: Thursday, February 15, 2007 11:03 AM
To: Klotz, Leigh
Cc: Fennell, Philip; www-forms@w3.org
Subject: Re: Bindings, relevance and implied attributes

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:06:31 UTC