OASIS Open Document Format for Office Applications (OpenDocument) TC

We had talked about modularizing the ODF schema previously. My colleagues at the IBM Tokyo Research Center did an investigation of the possibilities a while ago. I just recently received permission to share their report. Although it was looking at the ODF 1.0 schema, I think there are some good insights here. Regards, -Rob Attachment: ODFModularization.pdf Description: Binary data Attachment: smime.p7s Description: S/MIME Cryptographic Signature

Rob, On 10 November 2011 18:55, <robert_weir@us.ibm.com> wrote: > We had talked about modularizing the ODF schema previously.  My colleagues > at the IBM Tokyo Research Center did an investigation of the possibilities > a while ago.  I just recently received permission to share their report. > Although it was looking at the ODF 1.0 schema, I think there are some good > insights here. > This is very good news indeed. From what I can guess, it opens a lot of opportunities and conceivably accelerates the deployment of ODF (or modules thereof) on implementations able to run on mobile devices and the like. However, how does this affect the notions of conformity we have been trying to establish in the OIC TC? Just curious. Thanks Louis > Regards, > > -Rob > > >

Louis Suárez-Potts wrote: > On 10 November 2011 18:55, <robert_weir@us.ibm.com> wrote: > > We had talked about modularizing the ODF schema previously.  My colleagues > > at the IBM Tokyo Research Center did an investigation of the possibilities > > a while ago.  I just recently received permission to share their report. > > Although it was looking at the ODF 1.0 schema, I think there are some good > > insights here. > > > > This is very good news indeed. From what I can guess, it opens a lot > of opportunities and conceivably accelerates the deployment of ODF (or > modules thereof) on implementations able to run on mobile devices and > the like. > Hi Louis, did you read the report? It basically says, ODF is not (easily) modularizable, unless you change it incompatibly. I don't think that's really good news. I guess profiles would be more useful than this purely syntactic modularization... Cheers, -- Thorsten Behrens SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg; GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Attachment: pgpOZPYd67BYA.pgp Description: PGP signature

Hi On 14 November 2011 06:11, Thorsten Behrens <tbehrens@suse.com> wrote: > Louis Suárez-Potts wrote: >> On 10 November 2011 18:55,  <robert_weir@us.ibm.com> wrote: >> > We had talked about modularizing the ODF schema previously.  My colleagues >> > at the IBM Tokyo Research Center did an investigation of the possibilities >> > a while ago.  I just recently received permission to share their report. >> > Although it was looking at the ODF 1.0 schema, I think there are some good >> > insights here. >> > >> >> This is very good news indeed. From what I can guess, it opens a lot >> of opportunities and conceivably accelerates the deployment of ODF (or >> modules thereof) on implementations able to run on mobile devices and >> the like. >> > Hi Louis, > > did you read the report? not at the time I wrote my above…. (guess I should have) It basically says, ODF is not (easily) > modularizable, unless you change it incompatibly. I don't think > that's really good news. > Quite; but I was thinking that the effort alone, the idea that is somewhat desirable and that there is engineering resource to be engaged in it—I read that as good news. > I guess profiles would be more useful than this purely syntactic > modularization... > > Cheers, > Louis > -- > > Thorsten Behrens > > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg; GF: Jeff > Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) >

On 14.11.2011 12:11, Thorsten Behrens wrote: > I guess profiles would be more useful than this purely syntactic > modularization... Yes, modularization can be done once ODF V.nextnext is decided not to be backward compatible with current versions of ODF. Schematron can be quite useful in defining profiles. Regarding the IBM study -- I don't think that Garden of Eden is very appropriate schema style for ODF -- all elements will be allowed as potential roots. Jirka -- ------------------------------------------------------------------ Jirka Kosek e-mail: jirka@kosek.cz http://xmlguru.cz ------------------------------------------------------------------ Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing ------------------------------------------------------------------ OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member ------------------------------------------------------------------ Attachment: signature.asc Description: OpenPGP digital signature

Hi Rob, The report was very interesting in terms of schema design. I really do like their analysis of namespace dependencies, schema pattern and I share their observation on ODF schema naming inconsistencies. If there might be a refactoring of the ODF schema in the future, this report covers some preliminary work. On the other hand, in regard of modularization I fear the work is barely started. They based their concept solely on ODF syntax, just analyzing the dependencies of XML namespaces (prefixes) within the RelaxNG schema. Thy neither questioning the correctness of the given ODF prefixes (input), nor proofing their own statements (output) by user scenarios or user documents.   For example Figure 4 is showing their visioned module structure, but there is no dependency from the text module to the table, although a text document should be able to use tables. Their approach is like a semantic black box testing, solely focusing on syntax. Not even ODF MIME types were considered in their modularization attempt. Considering the large amount of ODF XML it seems obvious that modularization effort should start with the creation of a tool to analyze the ODF schema, for instance based on schema2template of the Apache ODF Toolkit.. Questions like: What is the minimal ODF document of a certain MIME type (minimal XML tree / empty document)? What (root) components can be added to such an empty document? What can be changed on components? What changes do I have to support? are best solved with the aid of automation. Svante Am 11.11.2011 00:55, schrieb robert_weir@us.ibm.com: We had talked about modularizing the ODF schema previously. My colleagues at the IBM Tokyo Research Center did an investigation of the possibilities a while ago. I just recently received permission to share their report. Although it was looking at the ODF 1.0 schema, I think there are some good insights here. Regards, -Rob