OpenDocument TC meeting minutes 2011-11-28 ========================================

-- Start 9:33 EST

-- Roll call

+Andreas Guelzow +Donald Harbison +Jos van den Oever +Louis Suarez-Potts +Ming Fei Jia +Patrick Durusau +Robert Weir +Robin LaFontaine +Steven Pemberton +Thorsten Behrens +Thorsten Zachmann

Voting Members are indicated with a + before their name

12/17 voting members present = 70%, so quorum requirements are met.

Membership Notes: None

-- Agenda is approved by unanimous consent

-- Distributed minutes have error: portion of previous week's minutes appended at end ==> Rob action item to send out amended minutes

-- ODF Maintenance

http://www.itscj.ipsj.or.jp/sc34/ -no posted teleconferences for WG6.

-- ODF 1.3 Change Tracking

Robin: revised consensus report for change tracking has been uploaded. Please review

-- Continuing discussion on schema modularization

Svante: the report used a "black box" approach without looking at how the namespaces are used in application

Svante: Automatic might happen as well by choosing to analyze the ODF schema

Svante: Empirical analysis of documents give us clues about the commonness of submodules of documents, their importance

Robin: Yes, tables are complex, and there are other 'standard' models such as CALS that might be considered.

Svante: Automated output could be condensed, by only collecting/listing the root elements of submodules/components of ODF.

Svante: For example, traversing the XML tree might only return the content between office:body/*

Svante: Root elements might be: text, table:table, text:section, etc.

Svante: @Robin: Module like CALS? What is root element?

Robin: @Svante: CALS would start at <table>

Robin: Use analysis could also consider the modularization work and see which 'inappropriate' syntax paths are used.

Rob: Need document collection (corpus) as well as query engine

Svante Schubert: http://odftoolkit.org/downloads/odfdom/OpenDocument-v1.2-draft/OdfReference.html#element_office:text_0

Svante: Children office:text are the root component of a text document

Svante: ^component^components

Svante: If we would put several XML together to a component, we would abstract XML details from the ODF user. Making the documentation easier, but not changing the semantic/ODF itself.

Svante: In the above case we might even summarize the components with the draw:* root elements as Drawing Shapes, easing again documentation similar to the headlines we use in our ODF 1.2 specification.

Svante: @Robin: <table> like <table:table>?

Svante: Just a note, if we would start looking for such components (puzzle pieces of XML) in ODF and start to specify those in ODF, we might even put RelaxNG annotations in our schema, allowing to generate HTML documentation as the given above on component level.

Robin: @Svante: yes

Rob: http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=5212557

Rob: "All common embedded subtrees for clustering XML documents by structure"

Jos: https://projects.kde.org/projects/calligra/repository/revisions/master/raw/tools/scripts/downloadMSOfficeDocuments.pl <- also for ODF

Rob: clustering sounds interesting

Svante: Full covered modularization is a gigantic task.

Svante: An open tool would be in need, to map XML tree(s) from the schema to components and their properties. If everyone could suggest mappings from XML to component/properties the Hercules task feasible

Svante: ^feasible^ would become feasible

Svante: Module levels similar to formula would be a big step for interoperability. If an application would guarantee to support the lowest feature set, the ODF user would have at least a change to find out if her/his documents would work.

Rob: Adjourned at 10:35 EST