RE: xforms for inhomogenous collections

Mark, 

	First, sorry for the delay in the response.  

	Second, I still don't understand it that way.  The line directly after:

"Inheritance Rules: If any ancestor node evaluates to XPath false, this value is treated as false. Otherwise, the local value is used."

is

"...This is the equivalent of taking the logical AND of the evaluated relevant property on the local and every ancestor node."

I understand this to mean that if I have 

	<a>
	  <b>
	    <c/>
	    <d/>
	  </b>
        <e/>
	</a>

and 
	
  <xf:bind nodeset="b" relevant="false()" />
  <xf:bind nodeset="c" relevant="true()"/>

Then all of these would still be false:

  <xf:output ref="b/d"/>
  <xf:input ref="b">
    <xf:label />
  </xf:input>
  <xf:input ref="b/c">
    <xf:label />
  </xf:input>

This understand still agrees with your statement of "The concepts of 'ancestor' and 'inheritance' all relate to the instance data."

If I am still wrong, would you please give me a different example.


Susan 

-----Original Message-----
From: Mark Birbeck [mailto:mark.birbeck@x-port.net]
Sent: Friday, December 19, 2003 9:18 AM
To: Borgrink, Susan
Cc: www-forms@w3.org
Subject: RE: xforms for inhomogenous collections


Susan,

>  ... what I stated was how I interpreted this line from the
> specification for the relevant property section 6.1.4.
>
> "Inheritance Rules: If any ancestor node evaluates to XPath false,
> this value is treated as false. Otherwise, the local value is used."
>
>  If that is not the case can you please explain to me what this
statement means.

There is nothing wrong with the spec. The issue is that you have mixed
up the UI and the model.

The concepts of 'ancestor' and 'inheritance' all relate to the instance
data. So if you have:

    <a>
      <b>
        <c />
      </b>
      <d />
    </a>

then if some rule makes <a> not relevant, unless some other rule makes
<b> and <c> relevant, then they too will be not relevant. That's the
meaning of the spec.

So, let's first set up a CSS rule so that the state of the model can be
reflected to the UI. I'll say that any form control bound to
non-relevant instance data is to have a blue background:

    <style>
      /* for formsPlayer */
      .disabled { background-color: blue; }
      /* for X-Smiles */
      *:disabled { background-color: blue; }
    </style>

Then we need a rule:

    <xf:bind nodeset="b" relevant="false()" />

With this rule, all of the following would have a blue background:

    <xf:output ref="b/c" />

    <xf:input ref="b"><xf:label /></xf:input>

    <xf:group ref="b">
      Some text here ... All in blue
      <xf:input ref="../d"><xf:label /></xf:input>
    <xf:group>

But note that the first control is blue because the instance nodes <c>
has inherited its relevant status from <b>. However, the xf:input using
<d> is blue only because it has inherited CSS properties from xf:group -
i.e., nothing to do with relevant. If you were to take the control out
of the xf:group then it would not be blue.

To complete the picture using my previous example, if we now create CSS
rules to hide form controls bound to non-relevant instance data:

    <style>
      /* for formsPlayer */
      .disabled { display: none; }
      /* for X-Smiles */
      *:disabled { display: none; }
    </style>

then the xf:input bound to <d> that is inside the xf:group would now be
hidden (along with the text). But as we've said, that would have nothing
to do with <d> inheriting a relevant property, since it is not a
descendant of <b> - instead it is to do with the CSS from the xf:group
propagating down.

I hope that helps. I know this is tricky, but if you're working on an
implementation then you have to get this type of thing exactly right;
the connections between the model and the UI are a large part of what
give XForms its power.

Best regards,

Mark


Mark Birbeck
CEO and CTO
x-port.net Ltd.

For 100% of the XForms spec:
http://www.formsPlayer.com/

Received on Monday, 29 December 2003 11:33:51 UTC