[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