Re: Bindings, relevance and implied attributes

Hi Leigh,

And I'm all for using workarounds. :) Schemas will do the same as what
you describe for DTDs. And of course, as I explained, there are also
workarounds for the more general problem. But my point in relation to
finding a more general solutions was that the workarounds don't scale.

Regards,

Mark

On 15/02/07, Klotz, Leigh <Leigh.Klotz@xerox.com> wrote:
> 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.
>
>


-- 
  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 20:47:30 UTC