RE: Sun Demonstates comprehensive XForms support in OpenOffice/StarOffice

Hi Slava,

Regarding your comments:
>i guess it not so good idea - to mix XForms model with OO control
>elements (at least for me it very bad news)

I'd have to agree. The main purpose of considering model-only types
of processors in XForms 1.1 is to allow for server-side processors
that need to effect the rules of a model without presenting the
form to a user.

A model-only forms renderer for the end-user loses a lot of really 
important functionality, like repeat 'tables' and the actions that 
operate over them.  It's hard to justify the qualifier 'comprehensive'
without support for these constructs.

The approach that *should* be taken to create host languages other
than XHTML for XForms is to think of the host language as a 'skin'
for the XForms elements.  This is actually analogous to the way XHTML
incorporates XForms: the XForms controls are embedded into the host 
document, and the markup around those controls provides additional context.

For example, XFDL has a very structured approach to specifying the UI
for many reasons including need for precision printing and security.
So, as with open office, XFDL has its own UI elements distinct from XHTML,
but the way we are merging those with XForms is by placing the appropriate 
XForms control inside of our controls.  This way, XForms provides the
specified functionality using the recommended vocabulary, and the XFDL 
host language 'skin' overrides with additional presentational context information.  

For example, suppose you want to present a currency value that is the result
of a calculation, such as the final result of an income tax return.  Well,
XFDL previously had a <label> control that not only presents a text string, but
has control over all aspects of its presentation like where it is, what color,
what font, etc. etc.  Since XForms provides the 'output' control for presenting
things like the results of calculations, it makes sense to let our <label>
control be a 'skin' for the XForms output:

<label sid="Tax">
   <xforms:output ref="totalTax"/>
   <fontcolor compute="value>='0' ? 'black' : 'red'/>
   <itemlocation>
	<after>Something</after>
	<expandr2r>SomethingElse</expandr2r>
   </itemlocation>
   <format>
      <datatype>currency</datatype>
      <presentation>
         <showcurrency>on</showcurrency>
      </presentation>
   </format>
   <visible>on</visible>
</label>

The 'value' that this label shows is, of course, obtained from instance data
as one would expect from an xforms:output.  The fontcolor, itemlocation and
other elements of the XFDL language decide things like where the label will be
and what it will look like.  The <format> option, for example, declares
the value to be a currency value, so locale-specific settings for things like
comma separation and currency symbol are used to dress up the result.  
Best of all, if you've spent any time with XForms, you've doubtless seen
the down side of having 14 digit precision, but the currency format in XFDL
accounts for that too. So, instead of seeing 1327.8963510374, you'd see
(in the US anyway) $1,327.90.  This is the type of value-add that a good host 
language can offer.

Of particular interest to the notion of host language as XForms skin, the 
XForms relevant MIP for the totalTax node is supposed to be available for styling 
by the host language.  In XFDL, the relevant setting is by default applied to both
the 'visible' and 'active' settings of the XFDL <label>.  So, a non-relevant 
node makes the label invisible and disabled by default.  However, the XFDL 
for this particular label explicitly declares the visible state to be 'on', 
which overrides the setting inherited from XForms.  So, this label would be 
visible, but still disabled.

My hope is that, as more host languages are developed, we will not see a lot
of host languages that "have XForms support" but leave out numerous *required*
parts of the language.  Moreover, even as we consider greater modularization
in 1.1, I would still think that things like the UI module would still be
classified as 'recommended' in the RFC 2119 sense, which means that it must be
supported unless there are *good technical reasons* for the omission.  That
a server doesn't present UI is a good technical reason.  I haven't yet heard another.

Best regards,
John Boyer, Ph.D.
Senior Product Architect and Research Scientist
PureEdge Solutions Inc.



-----Original Message-----
From: Slava Sedov [mailto:sedov@yandex-team.ru]
Sent: Tuesday, January 25, 2005 9:32 AM
To: Daniel Vogelheim
Cc: www-forms@w3.org
Subject: Re: Sun Demonstates comprehensive XForms support in
OpenOffice/StarOffice



Daniel Vogelheim wrote:

>
> Hello all,
>
> Sorry for the late answer. I must have overlooked this your mail when 
> it was sent. :-(
>
> > look like in content xml file most elements for OO forms
> > not in W3C XForms namespace (in W3C XForms namespace
> > now only the model element) is it temporary or it will be persistent?
>
> Yes, this is intentional. The OASIS OpenDocument format already has a 
> control + form layer, so we were faced with the option to either 
> duplicate all controls, or to bind the existing controls to the XForms 
> model. Simply duplicating would have been rather undesirable (and is 
> generally avoided in the remainder of the format as well), so we chose 
> to embed the XForms model as-is, but to reuse the existing controls.
>
> Transforming between those shouldn't be too hard. There are a few 
> differences, but mostly they follow a similar model. (Which is 
> probably due to the fact that both sets of controls were derived from 
> the HTML control set.)

i guess it not so good idea - to mix XForms model with OO control 
elements (at least for me it very bad news)

>
>
> > where i can find OpenDocument format description?..
>
> http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office

well... if it still in draft - why we can`t change it?..

>
> The format is developed through OASIS, so the documentation (and 
> information on participating or giving feedback) can be found on their 
> site. Follow the link to the specification document.
>
>
> > is it possible furure migration forms to xforms in OO?..
>
> Do you mean migrating existing OOo forms to OOo XForms? That is quite 
> easy, due to the use of the same controls: You only have to bind them 
> to an XForms model.

i mean changes in Open Document standard from OO to W3C XForms

>
>
> Hope this helps.
>
> Sincerely,
> Daniel
>
truly yours,
Slav

Received on Tuesday, 25 January 2005 23:46:11 UTC