Bindings, relevance and implied attributes

Hello,

As a result of some cogitation and rumination regarding Erik Bruchez
comment on my previous questions about relevance and control bindings I
can understand why XForms is how it is.

1) If the result of your binding expression is an empty nodeset then how
can you have a control change something that isn't there.

2) Given the declarative nature of XForms, it is possible to set-up a
mechanism (trigger + action) to add the attribute which generates events
that will result in the binding expression returning a non-empty nodeset
and thereby allowing the control to become accessible.

Now, seeing that the idea of having to interact with one control to
allow me to edit within another just because I want to introduce a
font-style attribute to an svg:text element strikes me as a bit pants!

I think my problems stem from the fact that attributes that I might want
to edit are implied attributes and in an example like SVG the absence of
a font-style attribute has the same visual result as the presence of
that attribute with a specific value e.g. font-style="normal". But,
before anyone says, 'why aren't you using CSS?' lets not go there
because that's not the issue.

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?


Regards

Philip Fennell

Received on Wednesday, 14 February 2007 11:00:35 UTC