- From: John Boyer <boyerj@ca.ibm.com>
- Date: Wed, 3 Nov 2010 09:45:37 -0700
- To: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
- Cc: "Forms WG" <public-forms@w3.org>
- Message-ID: <OFB1FCAF0C.71F7D5A3-ON882577D0.005954AB-882577D0.005C1257@ca.ibm.com>
We've done such a huge amount of work, and it behooves us to review that
work relative to new proposals for solving problems we may have already
worked on.
This is an example.
One issue with this proposal is that it seems to only be good at assigning
one property, due to being expressed as an attribute.
What if you want more than one? Space-separated lists are a marginal
solution when static, but imagine how bad it would be when computed.
By comparison, check out this module Nick wrote not that long ago:
http://www.w3.org//MarkUp/Forms/specs/XForms1.2/modules/model/bind/index-all.html
esp.
http://www.w3.org//MarkUp/Forms/specs/XForms1.2/modules/model/bind/index-all.html#N65990
Now, I personally prefer the name 'property' over 'mip', but that's minor
compared to the difference in structure. Each custom property has its own
element, so the expression that drives its dynamism is separated from
other properties on the same node. We'd also have the ability to
separately set the context of each property expression.
Another difference relative to the proposal below is that the element
version above has a type attribute that allows us to indicate what is the
expected result of the property whereas the proposal below seems to assume
only boolean properties. That aspect of the element version could be seen
as an advantage because it is generalized. For example, all existing MIPs
could alternatively be expressed using the property element. An advantage
of the proposal below is that it maps to existing limitations in CSS
properties, although we have worked around that limitation with
pseudo-elements. However, if the limitation to boolean properties is
desired, that could be as simple as not having a type attribute on the
property element for now. In other words, it still seems better to design
for the long term and choose a direction that has better growth potential
as long as doing so doesn't significantly obfuscate, which does not appear
to be the case here (in fact, the separation of multiple properties seems
to do the opposite).
Anyway, the meta-issue is that we have already discussed a number of
issues that we now still face, and we have already created a number of
solutions for them. Perhaps taking stock of those would be a good idea.
Quite a few solutions appear in the specs/XForms1.2/modules directory, and
further discussion and solutions appear here:
http://www.w3.org/MarkUp/Forms/wiki/XForms_2.0_Refactoring
Cheers,
John
From:
"Steven Pemberton" <Steven.Pemberton@cwi.nl>
To:
"Forms WG" <public-forms@w3.org>
Date:
11/03/2010 08:12 AM
Subject:
Proposal for Exists+Events+in/visible
Following on from our discussion yesterday, a strawman proposal that also
covers my more general case:
<bind ref="sum" property="if(.<0, 'negative', '')"/>
...
<output ref="sum"><label>Total: </label></output>
with CSS:
output.negative {color: red}
How a bound property maps to controls is host-language dependent, but for
XHTML it would add the property name to @class.
Steven
Received on Wednesday, 3 November 2010 16:46:19 UTC