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] office:body tag


Hi
 
As food for thought on today's call I just wanted to throw out a few comments and questions on the office:body tag and how it's contents relate to the value of office:class.
 
As I understand it the office:class attribute of the office:document tag describes the type of application that should process the contents of the office:body tag. That is if office:class is "spreadsheet" then the contents of the office:body tag will be a series of table:table elements that represent individual sheets in a spreadsheet or if the office:class is "presentation" then the contents of the office:body tag will be a series of draw:page elements that represent the slides of the presentation.
 
This results in a situation where one can create (by hand) a valid OpenOffice document that looks like this...
 
<office:document office:class="spreadsheet">
...
  <office:body>
    <table:table>...</table:table>
    <draw:page>...</draw:page>
  </office:body>
</office:document>
 
How are conforming applications supposed to deal with this? Why the decoupled approach? If we know a spreadsheet can contain only tables why not enforce it in the schema? Does the current flexibility of the office:body element have some long term benefit?
 
Let me suggest another possible way to do this. What if we make what is currently office:class attribute an element under office:body and then use the schema to constrain the contents of each class. For example in this system a spreadsheet would look like this...
 
<office:document>
  <office:body>
    <office:spreadsheet>
      <table:table>...</table:table>
      <table:table>...</table:table>
      <table:table>...</table:table>
     </office:spreadsheet>
  </office:body>
</office:document>
 
This way the schema could require that only table:table elements exist as children of office:spreadsheet, only draw:page elements exist as children of office:presentation, etc.
 
I would be interested to hear real world use cases where the current approach works but this approach does not. Is there a good use case for someone constructing a document like my first example?
 
Thanks
-Phil Boutros
VP, Technology
Stellent Corporation
pboutros@stellent.com
 


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


Powered by eList eXpress LLC