OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [office] Open Office XML Format TC Meeting Minutes 18/19 Feb 2003


MINUTES OF THE OASIS OPEN OFFICE XML FORMAT TC MEETING
FEBRUARY, THE 18TH/19TH, 2003, MENLO PARK, CA

Attendees
=========

Doug Alberg <doug.alberg@boeing.com>, Boeing
Phil Boutros <pboutros@stellent.com>, Stellent
Michael Brauer <michael.brauer@sun.com>, Sun Microsystems
Patrick Durusau <pdurusau@emory.edu>, Society of Biblical Literature
Gary Edwards <garyedwards@yahoo.com>
Paul Grosso <pgrosso@arbortext.com>, Arbortext
Jason Harrop <jharrop@speedlegal.com>, SpeedLegal
Tom Magliery <Tom.Magliery@corel.com>, Corel
Daniel Vogelheim <daniel.vogelheim@sun.com>, Sun Microsystems

Hartti Suomela <hartti.suomela@nokia.com>, Nokia (as an Observer)

Acceptance of Minutes of the February, the 10th meeting
=======================================================

- Jason Harrop is mentioned in the minutes, but did not attend to the 
meeting. Beside that, the attending TC members unanimously accepted the 
minutes.

Action Items
============

none


Discussion of Work Package 1.2 First Level Elements
===================================================

- The TC unanimously accepted to add an additional "genre" element for 
images within the "office:body" element.
- The TC unanimously accepted to replace the former class "text-global" 
with the genre element for "text" and an additional attribute that 
specifies that the document should behave like a master document rather 
than a normal text document.

Discussion of Extensibility
---------------------------
The TC discussed the extensibility of the OASIS Open Office XML schema. 
It identified the following possible requirements that have been 
discussed further:

A) The definition of custom properties, i.e. an arbitrary number of 
name/value pairs that can be added to a document.
B) The preservation of the custom properties defined in A).
C) A method to add attributes not specified by the Open Office XML 
schema to paragraphs and character runs that are preserved.
D) A method to allow character runs across paragraph boundaries.
E) Forward compatible processing of documents, namely processing of 
styles and unknown elements.
F) A specification how to deal with processing instructions.

The TC decided to use the term "_should_" for specifying application 
behavior that is strongly recommended, but not required to conform to 
the Open Office XML format specification, and the term "_may_" for 
application behavior that is considered to be useful (and wherefor 
recommended, too), but is considered to be less important than 
"_should_" behavior.

Discussion details:

A)+B) Custom properties
-----------------------
The TC unanimously agreed to add custom properties by adding "typed" 
meta data elements. These elements are similar to the already existing 
"meta:user-defined" elements, except that they have an additional 
attribute specifying the type of the custom property value (f.i. string, 
number, date, etc.). These custom properties _should_ be editable by 
conforming applications and _should_ be preserved when editing documents 
with conforming applications.
The TC unanimously agreed to add fields for referencing custom properties.

C) Attributes for paragraphs/character runs
-------------------------------------------
The TC agreed that styles are suitable and sufficient to further markup 
paragraphs and character runs (but also other object types like drawing 
objects), provided that
- attributes and elements that are contained in a style but are not 
specified in the Open Office XML schema are preserved, and
- multiple styles can be assigned to a paragraph, character run, etc.
Since current office suite implementations support only single styles, 
and since supporting multiple styles seems not to be easy to implement, 
the TC unanimously agreed to the following:
- A "class" attribute will be added to all elements that reference a 
style already. The value of this class attribute is a space separated 
list of styles that are applied to the object additionally to the style 
referenced by the "style-name" attribute. Formatting attributes 
contained in styles referenced by the "class" attribute are evaluated in 
the order the style names appear in the list. The style referenced by 
the "style-name" attribute is treated like being the first style in the 
list. Conforming application _should_ support this new attribute and 
also _should_ preserve it while editing.
- Attributes and elements that are contained in the "properties" element 
of a style but are not specified by the Open Office XML schema _should_ 
be preserved by conforming applications.
- To be usable in a list, styles referenced by a "class" attribute must 
not contain space characters. For this reason, a "display-name" has to 
be added to styles. A description is also considered to be useful by the 
TC. The schema details of classes will be discussed by e-mail on the 
TC's mailing list.

D) Character runs across paragraph boundaries
---------------------------------------------
The TC unanimously agreed that the extensions mechanism defined in C) 
can be used to support character runs across paragraph boundaries. Such 
runs can be split at the paragraph boundaries, and an (user defined) 
"id" attribute can be added to the style referenced by the two new runs 
to specify that both runs actually are a single one.

E) Forward compatibility
------------------------
As stated above, the TC unanimously agreed that conforming applications 
should preserve all attributes and elements contained in the 
"properties" element of styles and are not specified in the Open Office 
XML schema.
For all other attributes and elements that appear in a document but are 
not specified in the Open Office XML schema, the TC unanimously agreed 
that conforming applications _may_ preserve them. Additionally, the TC 
unanimously agreed to add a new attribute that specifies whether a 
conforming application should process the child elements of unknown 
elements or should ignore them. The attribute's default is to process 
them. If they should be processed, the document  has to valid against 
the Open Office XML schema if the unknown element is replaced with its 
content only.

F) Processing instructions
--------------------------
The TC unanimously agreed that conforming applications must read 
documents that contain processing instructions, and that they _should_ 
be preserved.


Discussion of Work Package 2 Meta information
=============================================

Additionally to the custom properties specified above, the TC 
unanimously agreed that the "office:meta" element can contain arbitrary 
elements. These elements _should_ be preserved while editing a document 
with conforming applications, but these application need not to support 
editing these elements.
The TC also unanimously agreed that all elements in the "office:meta" 
element might appear multiple times, but that the Open Office XML format 
specification does not specify how a conforming application handles this 
case when saving a document. It might keep the elements (seems to be 
appropriate for keywords), save only one (seems to be appropriate for 
editing duration), modify the first one (seems to be one possibility for 
author), etc.
The TC unanimously agreed to remove the "meta:keywords" element and 
instead allow multiple "meta:keyword" elements within "office:meta".

Discussion of Work Package 3 Text content
=========================================

- The TC clarified that tables bound as a character are covered by the 
more general concept of a text box that is bound as a character and 
contains a table.
- The TC started a discussion about the representation of lists, 
especially whether the list (container) elements are required. This 
discussion has been postponed until the next phone meeting.
- The TC unanimously agreed to rename the "tab-stop" element to "tab", 
and to add the an optional attribute to the "tab" element that specifies 
the number the tab stop in the paragraph's tab stop definition (contain 
in its style) the "tab" actually jumps to. The position "0" is reserved 
for the left (or start) paragraph margin, "1" for the the first tab stop 
in the tab stop definition. This feature should simplify transformations 
into XSL-FO.

Misc
====
- Daniel Vogelheim will chair the phone meeting on March, the 3rd.

New Action Items
================

- Daniel: Send link to updated TC spec/schemes maintained on OpenOffice.org
- Daniel: Suggest names for genre elements and attribute for master docs
- Editors: suggest Relax-NG schema changes according to the meeting 
decisions


Michael Brauer

OASIS Open Office XML format TC chair



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC