OpenDocument TC meeting minutes 2011-11-28

[robert_weir@us.ibm.com]

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