- From: John Boyer <boyerj@ca.ibm.com>
- Date: Sat, 2 Feb 2008 00:08:22 -0500
- To: Nick_Van_den_Bleeken@inventivegroup.com
- Cc: "public-forms " <public-forms@w3.org>
- Message-ID: <OF737C7192.9C61CFD7-ON852573E3.001A433D-852573E3.001C3B8D@ca.ibm.com>
Hi Nick,
I thought we had discussed a syntax that was better than the original
proposal, namely that each possible MIP could possibly be expressed by a
child element of the same name, whereupon the context attribute could be
used on that element. Like this:
<bind nodeset="c">
<calculate context=".." value="a + b"/>
</bind>
This has several benefits.
First, it is easier to say that the *bind* identifies the nodes to which
MIPs are applied, whereas the <calculate> element is only concerned with
providing a more sophisticated way of expressing the formula. There is no
confusion about what node the formula applies to because the context
attribute is not being placed on an inner bind. In other words, it is
easier to say that context on the calculate element only overrides the
evaluation context of the value attribute and does not interfere in any
way with the node to which the result of the formula is applied.
Second, it allows us to simplify the expression of boolean results. For
example, must we really call boolean-from-string() on expressions whose
result is known to be boolean? Specifically, the element relevant could
be defined as automatically applying boolean-from-string to the string
result of the value attribute in the following:
<bind nodeset="node/a">
<relevant context=".." value="b"/>
</bind>
It's up to the group to decide if they want this extra semantic for
relevant, readonly and constraint, but lots of people consistently forget
to put boolean-from-string() until they get burnt by it. Even if we used
'boolean' rather than 'value', it would be better, e.g.
<bind nodeset="node/a">
<relevant context=".." boolean="b"/>
<readonly context=".." boolean="c"/>
</bind>
Third, using MIP named child elements allows the possibility for
combinators on some of the MIP types, especially constraint, e.g. the
following would say that node a is invalid unless (b and c and (d or e)
and (not f)):
<bind nodeset="node/a">
<constraint context=".." operator="and">
<constraint boolean="b"/>
<constraint boolean="c"/>
<constraint operator="or">
<constraint boolean="d"/>
<constraint boolean="e"/>
</constraint>
<constraint operator="not" boolean="f"/>
</constraint>
</bind>
Cheers,
John M. Boyer, Ph.D.
Senior Technical Staff Member
Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com
Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed:
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw
Nick_Van_den_Bleeken@inventivegroup.com
Sent by: public-forms-request@w3.org
02/01/2008 06:20 AM
To
"public-forms " <public-forms@w3.org>
cc
Subject
Spec text for Unified_evaluation_context (Action 2008-01-23.1)
All,
Attached to this e-mail you can find a draft HTML and spec-xml version of
the work I did for
http://www.w3.org/MarkUp/Forms/wiki/Unified_evaluation_context.
In short I added the context attribute to bind and added an example of how
this enables you to 'simplify' your XPath expressions on MIPs.
Please have a look at it,
Nick Van den Bleeken
Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer
Attachments
- text/html attachment: Unified_evaluation_context.html
Received on Saturday, 2 February 2008 05:09:16 UTC