|robe...@us.ibm.com||Dec 5, 2011 6:37 am|
|Subject:||[office] OpenDocument TC meeting minutes 2011-11-28|
|Date:||Dec 5, 2011 6:37:27 am|
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: Children office:text are the root component of a text document
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: "All common embedded subtrees for clustering XML documents by structure"
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