OpenOffice.org Enhanced Forms

OpenOffice.org 2.0

Task ID(s)

#114856#

Category	Specification Affects

<Other>

Abstract

This document describes an enhanced forms solution for OpenOffice.org. The enhancement includes an improved user interface for designing and using forms documents, and an XForms-compatible new data model for defined XML. OpenOffice.org enhanced forms will enable customers to build competitive electronic forms solutions that integrate into existing, XML based and/or web-services based work flows.

i-Team

Specification Owner	DVO - Daniel Vogelheim	Daniel.Vogelheim@sun.com
Marketing (MA)		
User Experience (UX)	FL – Frank Loehmann	Frank.Loehmann@sun.com
Development (DEV)	DVO - Daniel Vogelheim FS – Frank Schönheit LO – Lars Oppermann	Daniel.Vogelheim@sun.com Frank.Schoenheit@sun.com Lars.Oppermann@sun.com
Quality Assurance (QA)	MSC - Marc Neumann	Marc.Neumann@sun.com
Documentation (DOC)		

Specification Reviews

Version	Reviewer	Comment
Reviewed by UX <Date>	<Name>	<Comment>
UI String Review <Date>		
Reviewed by QA <Date>		
Reviewed by DOC <Date>		

Document History

Version	Author	Comment
Draft Sept 10, 2003	Daniel Vogelheim	chapters 1, 2, 4 complete (except for some technicalities)
Draft Sept 12, 2003	Daniel Vogelheim	Incorporate feedback
Draft Sept 24, 2003	Daniel Vogelheim	complete specification
Draft February 10, 2003	Frank Loehmann	Insert bookmarks
Final <Date>		

Contents

Glossary	1

References	2

1	Motivation	2

2	Goals	2

2.1	Secondary Goals	3

3	Dependencies	3

3.1	Technical Dependencies / Requirements	3

4	Detailed Specification	3

4.1	Form Concepts	3

4.2	User Interface Concepts	4

4.2.1	Form Design Mode	4

4.2.2	Form Use Mode	5

4.2.3	Normal Document Mode	5

4.2.4	Mode Summary	5

4.3	Elements of the Form-Specific User Interface	6

4.3.1	Data Navigator	6

4.3.2	Form Navigator (already in previous versions)	6

4.3.3	Property Browser (enhanced from previous versions)	6

4.3.4	Control Toolbar (modified from previous versions)	7

4.3.5	Form Toolbar (modified from previous versions)	7

4.4	Controls & Their Properties	7

4.4.1	Form Value Text Field	8

4.5	Data Models	8

4.5.1	XML Data Model	8

4.5.2	Database (SQL) Data Model	8

4.5.3	Name/Value pairs (HTML, PDF)	9

4.5.4	Other Data Models (Calc cell, Writer fields)	9

4.6	Repeatable Data	9

4.6.1	Repeatable Text Sections	9

4.6.2	Repeatable Table Rows	9

4.6.3	Repeatable Text Spans (OPTIONAL)	9

4.7	API	9

4.8	Miscellaneous	10

4.8.1	XML Form AutoPilot (PLANNED OPTIONAL)	10

4.8.2	Spell check	10

4.8.3	Export	10

4.8.4	Web-Services support	10

4.8.5	Protect Form Design Mode	10

4.8.6	File Format	10

4.9	<String Lists>	10

4.10	Error Conditions	11

5	Future Tasks	11

5.1	Security (Digital Signatures)	11

6	Legal Issues	11

7	Notes	11

Glossary

Term	Description
binding	OpenOffice.org Enhanced Forms distinguish between a form user interface element (a control) and the data store (a data item). A control must be bound to a data item, to make the control store its data in said data item. The programmatic representation of this connection between a control and a data item is called a binding.
binding expression	In XForms, bindings are described by binding expression. An XForms binding expression mainly consists of an XPath expression.
control	A control is a user interface element which allows the user to enter data (or initiate actions) in a form. Commonly used controls include text fields, check-boxes, or buttons. A control stores its data into a data item, to which it must be bound.
data item	A data item stores one value a users enters into a form. A data item can be bound to a control, meaning that said control's input will be stored in said data item.
data model	A data model stores the data a user enters into a form. One could say a data model constitutes the entirety of all data items. There can be different data models, such as an XML data model, or an SQL data model.
data navigator	A (new) user interface element that allows access to a document's data model, typically by displaying the data items in a tree structure. Cf section 4.3.1, Data Navigator.
form design mode	A user interface mode customized to create and edit form documents.
form document	A form document is a conventional office document with an embedded form layer.
form layer	Those parts of a document that are directly form related, in particular the logical forms, the form controls, the data model, and the controls' data bindings.
form navigator	An (existing) user interface element that allows access to a document's controls and logical forms. The main display is a tree structure with the document's logical forms as parent nodes, and the controls as leaf nodes. Cf section 4.3.2, Form Navigator.
form use mode	A user interface mode customized to fill out electronic forms. Cf. section 4.2, User Interface Concepts.
live mode	A user interface mode which operates just like the normal document mode, but allows filling out form controls. Section 4.2, User Interface Concepts.
logical form	A logical form ties together a set of controls for form submission or storage. Essentially, a logical form assigns certain common properties to all its constituent controls. Every control belongs to one logical form. Cf. section 4.2, User Interface Concepts.
normal document mode	The normal user interface mode, without any document specific functionality. Normal document mode is what you get when opening any text document. Cf. section 4.2, User Interface Concepts.
XForms	The XForms markup language describes the behavior of electronic forms. XForms markup must be embedded into a host language, which describes the form except for the actual form controls. In our parlance, XForms describes the form layer. Typical host languages for XForms are W3C's XHTML and SVG.
XML	XML, Extensible Markup Language, is a standard markup language for encoding structured information. Cf. the references section.
XML tree	An XML document implicitly describes a tree structure, sometimes called XML Infoset. The term XML tree refers to this tree structure. Cf. the references section.
XPath	XPath is an expression languages which works on XML documents. An XPath expression can be evaluated on an XML tree. XPath is used in XForms to describe control bindings. Cf. the references section.

References

XML 1.0 - http://www.w3.org/TR/REC-xml

XForms 1.0 - http://www.w3.org/TR/2002/CR-xforms-20021112/

XPath 1.0 - http://www.w3.org/TR/xpath

Motivation

Recent years have seen widespread adoption of XML in business and government use around the world. With the OpenOffice.org/StarOffice XML File Format and OASIS standardization of same, OpenOffice.org has successfully taken a lead role in this development. However, a new class of XML applications has emerged within business and government use that cannot satisfactorily be handled by an XML Office file format: Electronic forms using XML.

Electronic forms are on their way to replace paper forms as the primary means of capturing, transmitting, storing and processing formal business data. Their content is typically coded in XML for storage and transmission. Examples for such forms include the United Nations eForms initiative, the inter-industrial Universal Business Language (OASIS UBL) initiative (with strong participation by Sun), or a number of government form applications such as pharmaceutical records in Sweden. The commonality of all these projects is that 1) they contain highly structured content encoded in a custom XML format, and 2) they use forms as a primary means to guide customers/citizens through entering this structured data.

Several competitive products and formats have emerged (or have been announced) on which XML form solutions can be built: InfoPath (Microsoft), XML PDF Forms (Adobe), XForms (W3C), as well as some lesser known and more specialized products, like JetForms (since acquired by Adobe) or LiquidOffice Form Designer (Cardiff). Unlike those competitors, OpenOffice.org currently cannot fulfill the requirements that those formats and initiatives impose. If OpenOffice.org cannot offer the required capabilities, we risk falling behind other competitors on the corporate desktop.

Goals

OpenOffice.org should allow its customers to create and deploy electronic data entry forms for custom XML formats.

OpenOffice.org needs to be 'solution compatible' with competitive products. This means it should be possible to build a OpenOffice.org forms solution for any such deployment utilizing the competitive product(s).

To achieve this, OpenOffice.org forms will be enhanced in the following areas:

It will be possible to bind OpenOffice.org forms to an arbitrary XML data source, e.g. given by an XML file, a schema, or hand-edited by the user.

The forms user interface will be changed to allow straightforward creation of such forms.

The forms user interface will be improved for easier forms data entry, and will be made more similar to competitive products customers may be used to.

Form data validation logic will be improved, so that basic form logic for checking data validity can be achieved without using macros.

Secondary Goals

Several additional opportunities arise from an improved form support. They are covered in this specification; their implementation has only reduced priority. These secondary goals are:

supporting export to multiple output formats such as PDF and (X)HTML + XForms. This may allow OpenOffice.org to establish itself as a multi-format forms creation tool.

integration of database and XML forms functionality. This may provide customers with an easy migration path between those two worlds.

the integration of forms with conventional Writer documents (or other document types). A use case for such mixed documents might be a specification such as this, with a cover page consisting of a form and the remainder of the document being a traditional text document. Mixing forms and normal documents allows flexibility beyond what the competitive products offer.

Dependencies

Technical Dependencies / Requirements

Implementation of this feature requires close coordination with the implementation of the Database PCD.

Implementation of security features (currently listed as a 'future task') would depend on the XML security PCD.

Detailed Specification

Form Concepts

The current design allows to embed a form layer into documents of all types. This form layer contains a number of controls, plus information about a database table (or query) to which controls can be bound, as well as an URL for form data submission. Controls are positioned using the means of their host applications, meaning text anchoring for Writer documents, cell anchoring for Calc, absolute positioning for Draw, etc.

The enhanced forms are to follow the same concept of a form layer embedded into a host document. However, enhanced forms allow different data sources for controls, especially database tables (and queries) as before, and also XML trees. The binding of controls to XML trees should follow the XForms W3C standard.

In addition to these capability enhancements, enhanced forms feature a task-centric user interface for creation and use (filling out) of forms. This is to be achieved by suitably configuring a host application for form documents, e.g. by changing toolbars/menus to allow easy access to form design functionality, or by switching the main content into read-only mode when using a form.

Another much needed addition is improvements in the data-validation logic. Enhanced forms should be able to perform simple validation of input data, and give users clear and understandable feedback if values are out of range or otherwise invalid. Form authors should be able to prevent form submission when values are invalid, or insufficient input has been given.

User Interface Concepts

The user interface for enhanced forms will support two form specific modes to allow easy access to forms functionality. These specific modes are predefined customizations of the existing, general-purpose user-interface. For example, menus and toolbars (both are customizable) will be preconfigured with form-specific entries. This will not offer additional functionality, as a user could configure the same menus and toolbars into the general purpose document interface. But it allows far easier access, as most users do not customize their interface.

Form Design Mode

Designing a new form typically starts by selecting “File->New->XML Form” from the menu. This brings up a new document in form design mode, as well as an initial form dialog (or wizard) which guides the user through choosing a data source.

Editing in form design mode will typically consist of:

editing text (as in a word processor),

drag data items from the data navigator into the text editing area

(alternatively, insert controls by single-clicking on the toolbar, and binding the controls using the data navigator or property browser)

editing control properties using property dialogs accessed through the context menu or form navigator.

Form design mode brings up the Writer, with the following changes to its UI:

The 'form' toolbar is enabled and visible.

The 'form' toolbar contains buttons for 'form design mode', 'form use mode', 'form navigator on/off', etc.

The 'controls' toolbar is enabled and visible.

The 'controls' toolbar contains buttons for inserting controls, e.g. labels, buttons, text fields, etc. The toolbar also contains a button to switch into 'form use mode' (see below).

The menu bar contains a 'Forms' menu, which offers access to the items of the two previously mentioned toolbars

The forms navigator is enabled, visible, and docked in the upper right corner.

The forms navigator displays a tree view of all controls in the document. It allows easy access to all control properties, and it can be used to locate a control in the document.

The data navigator is enabled, visible, and docked in the lower right corner.

The data navigator displays a tree view of the selected data source. It allows drag&drop creation of controls for data items, easy binding of controls to data items, and limited editing of data items. Also, it offers an overview of all available data items.

Note that the user is forced to make a decision about the form's type of data source at form creation time. Later on, the data source (and even type) can be changed (or additional data sources can be added), but it is expected that users typically choose one data source at the beginning and do not modify this setting throughout the document life time.

For XML forms , the data source dialog allows selection of any XML file to be imported as data model , or the user may start with an empty tree and edit the data later in the data navigator.

Form Use Mode

Loading a form document brings up the document in form use mode. In this mode, the user can enter form data and navigate through the form fields. Submission and saving of form content is possible if the form designer has placed suitable buttons in the form.

Use form mode brings up the Writer, with the following changes to its UI:

The document is brought up in 'read-only mode'.

Read-only mode allows the control to be used freely, but no content can be edited. Tab can be used to navigate between controls. Read-only mode also eliminates most menus and toolbars.

The toolbar provides a button to bring the document into form design mode or the normal document mode.

Normal Document Mode

Forms functionality is also available in the normal document editing mode. However, the form specific toolbars <TO BE DETERMINED: and menus > are not shown (although a user could enable them by choice). Form controls can still be switched between 'live' and 'edit' mode, just as they can in today's OpenOffice.org.

Mode Summary

The following table summarizes the various form-related modes a document can be in:

	controls editable	controls usable for data entry
normal document editing (already in current office)	normal document editing controls: movable, editable document content: editable form toolbars: disabled (default) data navigator: disabled (default) form navigator: disabled (default)	form 'live' mode controls: ready for data entry document content: editable form toolbars: disabled (default) data navigator: disabled (default) form navigator: disabled (default)
form mode (new)	form design mode controls: movable, editable document content: editable form toolbar: enabled data navigator: enabled + docked form navigator: enabled + docked	form use mode controls ready for data entry document is not editable form toolbar: disabled data navigator: disabled (default?) form navigator: disabled

Switching between the modes horizontally (form design <-> form use; and normal <-> 'live') is facilitated by toolbar buttons. Switching vertically is not specially supported by the UI, and is only possible by manually changing the various UI elements to reflect the desired settings.

If a document cannot be saved (i.e. after http download, or lack of write permission), a document is brought up in read-only mode. Currently, read-only mode allows using controls for data entry, but prevents changes to the document content. <TO BE DETERMINED: Should read-only mode work the same as it does now?>

Currently, UI changes are saved on a per-document class, i.e. one configuration is saved for the Writer. This will be changed to save the configuration independently for various form modes.

Elements of the Form-Specific User Interface

For better ease-of-use, several form specific user interface elements are available to the user. This document contains only a brief description for many of these items. For in-depth description of those UI elements, the reader should refer to the particular specifciation.

Data Navigator

The data navigator gives easy access to the XML tree that is used as data model for the current form. The main display of the data navigator is a tree structure whose nodes are the nodes of the XML tree (elements, attributes, and character runs).

The data navigator provides functionality to :

display the data model (i.e., the XML tree) with its current data values.

manipulate the data model (i.e., the XML tree).

(add, delete, and edit the elements, attributes, and character nodes in the XML tree.)

bind a selected control to a data item.

(automatically generate a suitable XForms binding expressions for a given data item.)

select/find a control bound to a certain data item by double-clicking on it.

The detailed UI specification for the Data Navigator may be found here: <TO BE DETERMINED>

Form Navigator (already in previous versions)

The form navigator provides quick access to all controls and logical forms in a document. It displays a tree with logical forms as nodes, and all controls as leaf nodes.

The form navigator provides the following functionality:

Display all controls and logical forms.

Access the forms' or controls' property dialog / property browser.

Move controls between logical forms.

Property Browser (enhanced from previous versions)

The property browser allows the user to edit all aspects concerning a single control or a group of controls. It is a mode-less dialog that displays the properties of the currently selected control(s). If several controls are selected, the property browser displays a suitable subset of the options available for the respective selected controls.

Due to its mode-less nature, the property browser displays the properties of the current selection, and is updated whenever the current selection changes. Changes made to these properties will be applied to the selected control(s) whenever the 'apply' button is pressed, or whenever the user selects a different control. (The user can back out of these automatic apply using Undo.)

To accommodate both new and experienced users, the property browser features two modes: An easy mode, which will have all commonly used properties available as tabbed dialogs suitable to the selected control. Alternatively, an advanced mode can be used, which distributes all properties across several tab-pages for different categories, where each such tab-page lists all properties in a tabular format with name and edit box for changing the value.

The detailed UI specification for the Property Browser may be found here: <TO BE DETERMINED>

Control Toolbar (modified from previous versions)

The control toolbar contains buttons for all supported controls. A single click on a control button will insert the control at the current cursor position.

Compared to the current forms toolbar, the control toolbar will contain the first row of control buttons. Insertion will work as single-click.

<TO BE DONE: insert graphics of toolbar>

Form Toolbar (modified from previous versions)

The form toolbar contains buttons for form-related functionality, other than inserting controls.

The set of supported controls will be:

change form mode (form use mode, form design mode)

open data navigator

open form navigator ('Form Navigator...')

open property browser ('Control Properties...')

open property browser for form ('Form Properties...')

change/edit tab order ('Activation Order...')

open form in design mode (as opposed to the use mode default) ('Open in Design Mode')

??? ('Automatic Control Focus')

??? ('AutoPilots on/off')

Compared to the current forms toolbar, the new form toolbar will contain most of the buttons from the second row.

<TO BE DONE: insert graphics of toolbar>

Controls & Their Properties

The set of supported controls is largely identical to that of the previous versions. Additions (like a new rich text control) to the control set are discussed in the database PCD. (cf. <TO BE DETERMINED>)

To accommodate the new XML data model, all controls will have additional properties for their XML data binding (when they are part of an XML form). There are two binding properties: The first lets the user choose from a list of known XML element ID values, plus a special value 'binding expression'. If binding expression is chosen, a text property allows entering an XForms compliant binding expression.

The list of supported controls is:

push button

option button

check box

text box

list box

combo box

image button

image control

file selection

date field

time field

numerical field

formatted field

currency field

pattern field

table control

rich text control (new! Cf. Database PCD.)

Non-editable controls:

label

group box

Form Value Text Field

For forms embedded in Writer, a new text field that can display data items is introduced. This field can display the same data items as other, already existing controls, <TO BE DETERMINED: Which ones? text box/numerical field/formatted field/pattern field?>, but as a text field it is fully integrated into the text layout engine, resulting in much better integration of form content into text content.

Data Models

On a technical basis, each form can have a different data model. A data model is a collection of data items to which controls can be bound. Previous versions of OpenOffice.org support only a single data model, which uses an SQL row-set (a row from a database table or query) as data model. In this model, each column constitutes a data item to which controls can be bound. For enhanced forms, additional data models are supported, most notably an XForms compatible data model, which uses an XML tree as data model, and each element and attribute (addressable by XPath or element id) constitutes a data item. This XML data model is the default data model for the new forms, and has been the only one addressed in this proposal so far. This section will list the available data models and the options they offer to the user.

XML Data Model

The XML data model provides an XForms compatible way of binding controls to elements and attributes of an XML tree. The XML tree containing the current instance data is part of the document. It may be submitted to a web service, if the form designer includes a suitable submit button. Also, the XML tree can be saved to disk separately.

<TO BE DETERMINED: Can an XML tree also be loaded (or downloaded) separately? This would be very desirable. Can the XML tree be copied to/from the clipboard? Both may cause problems with invalid trees. Can a separate XML tree be loaded, and OpenOffice.org opens a suitable document along with it? Can the XML tree be used through 'File->Send to'? Can an XML tree be loaded (inserted, merged) directly from another document?>

The data items in the XML data model are all attributes and elements of the XML tree. They can be addressed either using id values or using XPath expressions, which are the two binding mechanisms supported by XForms. The user may either specify either of these as a text expression, or by selecting the desired node in the data navigator. In the latter case, the system has to generate the proper text expression from the user's selection.

Database (SQL) Data Model

The database (SQL) data model provides a way to bind controls to a database. This model is already supported in previous versions of OpenOffice.org.

The data items in the database data model are the columns of a SQL table row or query row. They can be referenced using their name, or selecting a column name from a list of allowed column names.

Name/Value pairs (HTML, PDF)

The form support in HTML and PDF (prior to PDF XML forms) supports only a simple data model where each control stores its own data. If data is to be submitted, a list of pairs, control name and control value, is sent to the server.

Other Data Models (Calc cell, Writer fields)

<TO BE DONE>

Repeatable Data

Paper based forms are necessarily static, in that paper provides no means to react to input. The canonical way for paper based forms to allow input of an unknown number of items is to provide a hopefully adequate number of repeated fields (e.g. delivered goods on an invoice). The user gets to fill in as many as needed, with the rest being left empty. For electronic forms, this can be improved by offering more dynamic forms that allow the user to repeat (insert, or delete) certain additional form elements into the form.

Repeatable data sections require close coordination of the forms layer with the host application. For Writer, repeatable sections are implemented using two (possibly three) different host application constructs: Text sections, tables, and optionally text marks. In each case, the form must contain a 'prototype' data section with suitable form elements and controls.

When filling out forms (form use mode, and 'live' mode) the user interface will display some sort of button or icon next to any repeatable section. Pressing the icon will open a menu which allows to add or remove repeatable elements. Switching between use and design mode changes the content of all repeatable data sections between the 'prototype' content (in design mode) and the data-dependent repeatable elements (in use mode).

Repeatable Text Sections

A repeatable text section allows the same content as a normal text section. Every control bound to section content (i.e. anchored as or to a character, and anchored to a paragraph) is considered part of the repeatable section. For easier implementation, a repeatable section contains an outer section, and inner sections for each repeated element.

If a new element is added to a repeatable text section, a new copy of the 'prototype' section is added. All controls bound to the section are copied into the new text section.

Repeatable Table Rows

Repeatable data in tables allows additional rows to be inserted (or deleted). A 'prototype' row contains all data and controls that will be copied into any new rows.

Repeatable Text Spans (OPTIONAL)

<NOTE: implementation effort vs. user benefit of this option needs to be discussed.>

Repeatable data can also be denoted by a text mark. If additional elements are being inserted, the text contained in the 'prototype' text mark is inserted at the proper location, as if the user had selected the 'prototype' text mark area and copied it (using copy and paste) right behind the other repeatable data elements.

API

To allow custom form logic to be integrated, full access to the XML tree that is used as a data model will be available through the OpenOffice.org API.

Miscellaneous

XML Form AutoPilot (PLANNED OPTIONAL)

<NOTE: this sub-project would have a different owner (BC), so this needs discussion with BC, DL>

The current form AutoPilot lets the user choose a number of data items from a SQL data source, and then guides the user through a number of options (mainly concerning layout) and finally generates a form containing controls for the chosen data items, placed according to the given layout preferences.

This AutoPilot is to get a sibling for XML forms. The only difference to the SQL form AutoPilot is the selection of data items. For the XML form AutoPilot, the user selects an XML file as data model . The AutoPilot then offers the user the following data items for selection:

all attributes in the data model

all elements in the data model that either

have an ID value,

have no element nodes as children

<TO BE DETERMINED: no element nodes, or rather: only text nodes>

Spell check

In forms use mode, control content should be subjected to OpenOffice.org's spell checking. This is covered in the database PCD.

Export

<TO BE DONE: export to PDF, XHTML/XForms>

Web-Services support

<TO BE DONE: support form data submission through web-services protocols, such as SOAP or webdav>

Protect Form Design Mode

<TO BE DETERMINED: should switching from form use mode to form design mode be password protected (optionally). Similar functionality is apparently available with competitors.>

File Format

<TO BE DONE: file format representation of enhanced forms>

<String Lists>

<Required - Dialogs providing strings which have to be translated, have to be accompanied by a table containing the strings used in the image (English or German or both) Strings have to include mnemonics and the item for which the string is used. Mnemonics have to be visualized by a ~ - symbol in front of the letter which has to be displayed mnemonic.>

String list

Item	English	German	Comments
Button	~Delete	~Entfernen	

Tab Order

<Required. It makes sense to describe or visualize the tabbing order. The description of the tab order has to contain which control has the initial focus.>

Key Board Shortcuts

<Required - Key Board shortcuts used in dialogs have to be listed in a table with a small description.>

Error Conditions

<Required - List all error conditions, and the action the system takes about them. If an alert box comes up, which kind is it? Include exact text of messages, or say what points need to be covered. Error Messages need a string list>

Future Tasks

Security (Digital Signatures)

Digitally signing form data or form with its data would enable OpenOffice.org Enhanced Forms to be used in legal and contract use cases. Reasons for not implementing this at this point in time are:

Presumably high implementation effort.

It is yet unclear how to do this. Digital signatures are under discussion for a future version of XForms.

Legal Issues

No legal issues have arisen so far.

Notes

Some notes and comments are interspersed in chapter 4, Detailed Specification, either as footnotes or marked by angle brackets.

Additionally, a menu item “File->New->Database Form” may be offered. However, a better place to offer such functionality may be the (planned) database application.

For database forms, a corresponding dialog would allow selection of any OpenOffice.org data source, and of a table or query within the data source.

If implementation time permits, it may also allow selection of a DTD or XSD or RELAX-NG schema.

Comment FL: I think we have to talk with MMP/CJ if we can show a new main menu entry during runtime of OO.org when the Forms functionality will be enabled in a Writer, Calc or Draw doc.

TODO: ask MBA whether/how this is possible

If a document supports several form models, there should be a way to access all of them; this should not complicate the normal single model case, though.

For SQL forms, the Data Navigator should display the table structure of the current table/query.

Comment DVO: Do all of these controls make sense for XForms? It may be necessary to disable some that are not suitable for XML forms.

Comment LO: Form submission should be bound to some meaningful dispatches in the framework, so that plugins can be developed that allow for communication with various backends, also generic signature mechanisms could be integrated in this fashion.

In later versions, this may be extended to support multiple 'prototypes' per repeatable data section. This is considered for inclusion in future versions of XForms.

Alternatively, a schema could be selected from which the data source is created. I consider that functionality optional, though.

<Required – This paragraphs gives the audience idea of what to aspect from this document. It should be described shortly what problem will be solved.>

The source of software product implementation and change is the I-Team (Implementation Team). I-Teams are typically comprised of people who have skills in the areas of Product Marketing, Development Engineering, Technical Publications, and Test Engineering. I-Teams define the features or set of changes (based on input from SCs, customers, Engineering, or Marketing), plan the implementation project, perform the implementation and testing...

Recommended - Please list of technical terms or specialized field of knowledge here.

Required - Give references to related documentation, such as engineering designs, technical specs, and other sources for related units. Also include links to documents that other sections in this spec need to refer to, such as user opinions usability test reports.

<Required - What is the reason for pursuing this project?>

<Required - The goals section must be short but also provide a clear statement of the goals, to achieve with this feature, project or task. A clear statement in this section gives the Development, Quality Assurance and Documentation guidance.>

<Recommended - Are there any requirements or dependencies for this feature? Does the implementation of this feature create any requirements/dependencies to other program parts?>

<Required - First of all the concept section should give the audience an overview of how the new feature will work. When this is done this section has to cover the necessary things to finish this feature. This is the crucial part of the specification. If images are used in the concept, it is very important that these images provide a caption. The caption should be short and has to describe shortly the image. UI Mockups has to provide a caption too, if possible the mockups shouldn't be scaled and our standard user interface font, Andale Sans UI has to be used for strings on dialogs.>

<Required - Dialogs providing strings which have to be translated, have to be accompanied by a table containing the strings used in the image (English or German or both) Strings have to include mnemonics and the item for which the string is used. Mnemonics have to be visualized by a ~ - symbol in front of the letter which has to be displayed mnemonic.>

<Required. It makes sense to describe or visualize the tabbing order. The description of the tab order has to contain which control has the initial focus.>

<Required - Key Board shortcuts used in dialogs have to be listed in a table with a small description.>

<Required - List all error conditions, and the action the system takes about them. If an alert box comes up, which kind is it? Include exact text of messages, or say what points need to be covered. Error Messages need a string list>

<Recommended - If there are features which couldn't be implemented but have to be implemented in the future. State these in here with a description why the feature couldn't be implemented right now.>

<Recommended - If there are any legal issues to deal with the should be described here. Legal issues could be for example we have to redistribute third party technology. This section can also contain links the Legal Review Tool.If the Specification will be published on OpenOffice.org this section has to be removed.>

<Recommended - Questions will arise during the writing of the specification. State these in here.>

Enhanced Forms

Page 10

http://specs.openoffice.org/appwide/xforms/EnhancedFormsSpecification.sxw

Enhanced Forms

OpenOffice.org forms XML XForms

Daniel Vogelheim

2004-02-06T15:28:01