RE: Made some updates to the bind module

We did discuss some of these points, though not the CSS.

Additionally, John and I pointed out that, for schema validation and
authoring tools, the bind reference to the defined mip should be a fixed
name, rather than using an attribute whose name is derived automagically
from the other content in the host document.  Thus we might see
  <mip id="overdue" type="xs:boolean" cascade="false" />
  <bind nodeset="due-date"><property mip="overdue"
value="(days-from-date(now()) - days-from-date(.)) &gt; 30" /></bind>

"property" seems a better name than "mip" for the child of bind.  As
Nick pointed out, the attribute tying the two together (as in
submit/@submission referring to submission/@id) should be the same name
as the defining element with the id.  Here it's bind/property/@mip
referring to mip/@id.  I don't think the name mip is correct for this
case.

Finally, Charlie pointed out that custom mips aren't on the plate for
this round, but I suggested that we go ahead with the design work in
order to test whether the bind/property element mechanism for the task
at hand is forward compatible.  (The real task is actually not mentioned
here.)

Leigh.

-----Original Message-----
From: public-forms-request@w3.org [mailto:public-forms-request@w3.org]
On Behalf Of Mark Birbeck
Sent: Friday, January 09, 2009 3:46 AM
To: Nick_Van_den_Bleeken@inventivegroup.com
Cc: public-forms@w3.org
Subject: Re: Made some updates to the bind module


Hi Nick,

Sorry I wasn't able to make the call yesterday, and join the discussion
on your latest draft.

I do have some comments on the new <mip> element, which I think needs a
little more added to it.

You've captured well some of the key aspects of a MIP:

 * that it has a type, such as boolean;
 * that it may or may not cascade;
 * that the value of a MIP on a node might override the cascade, or not.

But there are some other things that need to be added:

 * that a MIP can set a CSS class on bound controls;
 * that a MIP will fire events to bound controls.

So my first suggestion is that your <mip> element should move out of
<bind> and be something that is standalone. This allows it to define
attributes that can be used in subsequent bind statements:

  <mip name="overdue" type="xs:boolean" cascade="false" />

Next we need to show how, if an author creates such a custom MIP
definition, CSS classes will be set and cleared automatically, on any
controls that are bound to nodes that have this property. As usual,
naming is tricky here, but to start the discussion off, we might
consider:

  * mip-overdue-on;
  * mip-overdue-off.

The key point is that the class name is generated using a standard
pattern that the form author can anticipate, such as:

  * mip-[name of customer MIP]-(on|off)

or:

  * mip-[name of customer MIP] and;
  * mip-not-[name of customer MIP].

We also need to define a pattern for the events that are generated, such
as:

 * xforms-mip-overdue-set;
 * xforms-mip-overdue-cleared.

Once again, the names will no doubt be up for debate, but it needs to be
a fixed pattern, such as:

  * xforms-mip-[name of customer MIP]-(set|cleared)

To use a definition, an author would then do something like this:

  <mip name="overdue" type="xs:boolean" cascade="false" />

  <bind
    nodeset="due-date"
    mip-overdue="(days-from-date(now()) - days-from-date(.)) &gt; 30"
  />

  <style>
    .mip-overdue-on { background-color: red; }
  </style>

  <xf:input ref="due-date">
    <xf:label>Due date:</xf:label>
    <xf:message ev:event="xforms-mip-overdue-set" level="modeless">
      Your library books are overdue! We'll be round...
    </xf:message>
  </xf:input>

Note that the attribute is called "mip-overdue", rather than "overdue",
only to ensure that an author doesn't inadvertently attempt to create an
attribute that already exists. Another way to do this would be to use
namespaces, such as "mip:overdue".

Regards,

Mark

On Tue, Jan 6, 2009 at 4:56 PM,
<Nick_Van_den_Bleeken@inventivegroup.com> wrote:
>
> Hi,
>
> I made some updates to the bind module, the most significant change is

> the mip element to support custom MIPs and allow other modules to 
> build on this to create the reaonly, relevant, required,... MIPs.
>
> There are some things about this new element that we prob. should 
> discuss on a teleconf.
>
> You can find an update at
> http://www.w3.org/MarkUp/Forms/specs/XForms1.2/modules/model/bind/inde
> x-all.html
>
> Regards,
>
> Nick Van den Bleeken  -  Research & Development Manager Inventive 
> Designers
> Phone: +32 - 3 - 8210170
> Fax: +32 - 3 - 8210171
> Email: Nick_Van_den_Bleeken@inventivegroup.com
>
>
> Inventive Designers' Email Disclaimer:
> http://www.inventivedesigners.com/email-disclaimer
>
> --
> This message has been scanned for viruses and dangerous content, and 
> is believed to be clean.
> --
>



--
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street, London,
EC2A 4RR)

Received on Friday, 9 January 2009 17:25:36 UTC