MHonArc v2.5.2 -->
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC