Two concerns about realizing checkbox controls

> I've run into two unexpected issues with Orbeon's policies for realizing controls for boolean-valued elements.  In both cases what I view as a "reasonable" strategy for type definition essentially (I believe) confuses Orbeon into rendering elements of type xs:boolean as textboxes rather than checkboxes.
>
>
>
> The one strategy involves defining a boolean element's value as "fixed":  e.g.,
>
>
>
> <!-- define a common base type for a family of definitions  -->
>
> <xs:complexType name="my_base_type"  abstract="true">
>
>     <xs:sequence>
>
>          ....
>
>          <xs:element name="some-item-1"  type="xs:boolean"/>
>
>          <xs:element name="some-item-2"  type="xs:boolean"/>
>
>          <xs:element name="some-item-3"  type="xs:boolean"/>
>
>          ...
>
>     </xs:sequence>
>
> </xs:complexType>
>
>
>
> <!-- define a concrete realization of this base type that defaults the value of one item and fixes another -->
>
> <xs:complexType name="my_derived_type_for_my_base_type">
>
>     <xs:complexContent>
>
>           <xs:restriction base="local:my_base_type">
>
>                  <xs:sequence>
>
>                        ....
>
>                        <xs:element name="some-item-1" type="xs:boolean"/>
>
>                        <xs:element name="some-item-2" type="xs:boolean"  default="false"/>
>
>                       <xs:element name="some-item-3" type="xs:boolean"  fixed="false"/>
>
>                        ...
>
>                  </xs:sequence>
>
>            </xs:restriction>
>
>       </xs:complexContent>
>
> </xs:complexType>
>
>
>
> For instances of the derived type, Orbeon renders instances of some-item-1 and some-item-2 as checkboxes .... while rendering instances of some-item-3 as a textbox that contains the value "false".
>
>
>
> The other issue involves Orbeon's failure to treat types that are "trivially" boolean as such:  e.g.,
>
>
>
> <!-- define a type alias to synchronize definitions for related types. -->
>
> <xs:simpleType name="my_base_type">
>
>       <xs:restriction base="xs:boolean"/>
>
> </xs:simpleType>
>
>
>
> <!--  the following complex type is one of, say, 20 types that use my_base_type  -->
>
> <!--  and I'd really prefer to have this and the other types reference the common base type,
>
>     due to my immense respect for "once and only once-" (i.e., DRY-) style logic definition -->
>
> <xs:complexType name=".... whatever ...">
>
>       <xs:sequence>
>
>                ....
>
>               <xs:element  name="some-true-or-false-value"   type="local:my_base_type"/>
>
>              ...
>
>        </xs:sequence>
>
> </xs:complexType>
>
>
>
> For definitions such as these, XForms will realize some-true-or-false-value elements as textboxes rather than checkboxes.
>
>
>
> I know the second issue can be finessed using an XSLT application that uses a use-def analysis to replace trivial aliases for xs:boolean with xs:boolean proper;  I've written it, and we're using it to preprocess our schemas for use with Orbeon.  Still, it would be nice if Orbeon would provide an option for doing this analysis on a user's behalf... so long as the analysis wasn't cost-prohibitive  (note: since we're using self-contained VB-style schemas, my schema hacker runs pretty quickly.)
>
>
>
> As for the "fixed" attribute issue, I don't see as obvious of fix for this problem.  While it would be simple enough to write a second postprocessing application that replaces fixed="false" with default="false" in elements of type xs:boolean, that transformation really doesn't preserve the schema's semantics.
>
>
>
> Thanks for any help or advice, including pointers to dark corners of the XForms standard that I might have missed that would speak to these behaviors.
>
>
>
> Appreciatively,
>
>
>
> -- Phil
>
>
>
> ===================
>  Phil Pfeiffer/ East TN State U.     |  Kindness in thought leads to wisdom.
>  Dept. of CIS / P.O. Box 70711       |  Kindness in speech leads to eloquence.
>  Johnson City, TN.  37614-1266       |  Kindness in action leads to love.
>  [hidden email]<mailto:[hidden email]>  (423) 439-5355       |                            -- Lao-Tsu
>
>
> --
> You receive this message as a subscriber of the [hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> OW2 mailing lists service home page: http://www.ow2.org/wws
>

> I've run into two unexpected issues with Orbeon's policies for realizing controls for boolean-valued elements.  In both cases what I view as a "reasonable" strategy for type definition essentially (I believe) confuses Orbeon into rendering elements of type xs:boolean as textboxes rather than checkboxes.
>
>
>
> The one strategy involves defining a boolean element's value as "fixed":  e.g.,
>
>
>
> <!-- define a common base type for a family of definitions  -->
>
> <xs:complexType name="my_base_type"  abstract="true">
>
>     <xs:sequence>
>
>          ....
>
>          <xs:element name="some-item-1"  type="xs:boolean"/>
>
>          <xs:element name="some-item-2"  type="xs:boolean"/>
>
>          <xs:element name="some-item-3"  type="xs:boolean"/>
>
>          ...
>
>     </xs:sequence>
>
> </xs:complexType>
>
>
>
> <!-- define a concrete realization of this base type that defaults the value of one item and fixes another -->
>
> <xs:complexType name="my_derived_type_for_my_base_type">
>
>     <xs:complexContent>
>
>           <xs:restriction base="local:my_base_type">
>
>                  <xs:sequence>
>
>                        ....
>
>                        <xs:element name="some-item-1" type="xs:boolean"/>
>
>                        <xs:element name="some-item-2" type="xs:boolean"  default="false"/>
>
>                       <xs:element name="some-item-3" type="xs:boolean"  fixed="false"/>
>
>                        ...
>
>                  </xs:sequence>
>
>            </xs:restriction>
>
>       </xs:complexContent>
>
> </xs:complexType>
>
>
>
> For instances of the derived type, Orbeon renders instances of some-item-1 and some-item-2 as checkboxes .... while rendering instances of some-item-3 as a textbox that contains the value "false".
>
>
>
> The other issue involves Orbeon's failure to treat types that are "trivially" boolean as such:  e.g.,
>
>
>
> <!-- define a type alias to synchronize definitions for related types. -->
>
> <xs:simpleType name="my_base_type">
>
>       <xs:restriction base="xs:boolean"/>
>
> </xs:simpleType>
>
>
>
> <!--  the following complex type is one of, say, 20 types that use my_base_type  -->
>
> <!--  and I'd really prefer to have this and the other types reference the common base type,
>
>     due to my immense respect for "once and only once-" (i.e., DRY-) style logic definition -->
>
> <xs:complexType name=".... whatever ...">
>
>       <xs:sequence>
>
>                ....
>
>               <xs:element  name="some-true-or-false-value"   type="local:my_base_type"/>
>
>              ...
>
>        </xs:sequence>
>
> </xs:complexType>
>
>
>
> For definitions such as these, XForms will realize some-true-or-false-value elements as textboxes rather than checkboxes.
>
>
>
> I know the second issue can be finessed using an XSLT application that uses a use-def analysis to replace trivial aliases for xs:boolean with xs:boolean proper;  I've written it, and we're using it to preprocess our schemas for use with Orbeon.  Still, it would be nice if Orbeon would provide an option for doing this analysis on a user's behalf... so long as the analysis wasn't cost-prohibitive  (note: since we're using self-contained VB-style schemas, my schema hacker runs pretty quickly.)
>
>
>
> As for the "fixed" attribute issue, I don't see as obvious of fix for this problem.  While it would be simple enough to write a second postprocessing application that replaces fixed="false" with default="false" in elements of type xs:boolean, that transformation really doesn't preserve the schema's semantics.
>
>
>
> Thanks for any help or advice, including pointers to dark corners of the XForms standard that I might have missed that would speak to these behaviors.
>
>
>
> Appreciatively,
>
>
>
> -- Phil
>
>
>
> ===================
>  Phil Pfeiffer/ East TN State U.     |  Kindness in thought leads to wisdom.
>  Dept. of CIS / P.O. Box 70711       |  Kindness in speech leads to eloquence.
>  Johnson City, TN.  37614-1266       |  Kindness in action leads to love.
>  [hidden email]<mailto:[hidden email]>  (423) 439-5355       |                            -- Lao-Tsu
>
>
> --
> You receive this message as a subscriber of the [hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> OW2 mailing lists service home page: http://www.ow2.org/wws
>