Forms Proposal

[Daniel Vogelheim <Daniel.Vogelheim@sun.com>]

Hi all,

one of my action items was to suggest changes to the forms 
representation, since the current forms format has some OOo-specifics in 
them, and also some inconsistencies with the rest of the format.
Please find my proposal attached.

Sincerely,
Daniel



Forms in OOo Format

Each document has an (optional) forms section, which contains one or
more logical forms, which in turn contain all form
controls. Throughout the main document content, only <draw:control>
elements are used, which refer to one form control. The <draw:control>
element has the same attributes like shapes, including a graphics
style.

The control description inside the form element generally comprises:
- a form:control element,
  - a name attribute, which identifies the control in the user interface
  - a service-name, which identifies the control model implementation,
  - an id attribute, which is used by <draw:control> to identify the control
- a control-specific control element (form:checkbox, form:text, ...)
  - with control-specific attributes
- a form:properties element, containing <form:property> elements
  - which contain a form:property-name and form:property-type attribute
  - which contain a form:property-value child element
  - a property 'DefaultControl' contains a service name used to specify the
    control type to be instantiated


What's Wrong?

1) 'service name' refers to UNO services, which are OOo/SO-specific
2) the property name/type/value mechanism is non-consistent with the
   remainder of the format

Ad 1) OpenOffice.org uses a software componant model named UNO, which
allows to refer to any (binary) software components by name, dubbed a
service name. Since UNO isn't in widespread use outside of OOo, this
mechanism is OpenOffice.org specific, and should not be used for an
OASIS file format.

Ad 2) For internal consistency, we should try to make similar concepts
use similar representations. There are several instances of
name/type/value triplets, namely for table cell values, text field
values, form property, and for settings. Those should have the same or
similar representations.


Proposition

Ad 1) The actual issue with the service names is similar to that of
chart types, which we came across recently: We need to identify a set
of common services, and also allow for extensions. I think what we
basically want is some kind of namespaced token; in the conference
URLs were suggested, which would work, too.

Ad 2) The form:property element should be changed to use the same 
attributes for name/type/value that table cells and text fields use, 
i.e. one attribute for name, one attribute for value-type, type-specific 
attributes for the values.

[Q: table-cells also contain the presentation of the value as
content. Should this be supported, too? ]

Was:
     <form:property form:property-name="BlaBla" form:property-type="string">
       <form:property-value>BlubsBlubs</form:property-value>
     </form:property>
     <form:property form:property-name="Hidden" 
form:property-type="boolean">
       <form:property-value>false</form:property-value>
     </form:property>

Proposed:
     <form:property form:name="BlaBla" form:value-type="string"
                                       form:string-value="BlubsBlubs"/>
     <form:property form:name="Hidden" form:value-type="boolean"
                                       form:boolean-value="false"/>

3) It might also make sense to join the form:control element and
its child. An extension control would then have to create its own XML
element, which also solves the naming problem. Admittedly, I'm not
sure just how much of a good idea this is, so we probably
shouldn't... I just thought I mention it in case some comes up with a
good reason. :-)

4) formatted text fields:

The current specification features 'restricted' text fields, which
means text fields which accept date or time values. They have
minimum/maximum values, too. However, since the current format doesn't
tell you those are dates/times, there's no reasonable way to interpret
those. SO I propose we replace those by typed fields, with
date-values, time-values, and so on.