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] | [List Home]

Subject: Re: [office] Multiple object renditions proposal


> The current specification mixes the definition of a frame and its
> attributes (position, size, border, etc.) and the definition of it's
> contents. I believe the correct way to modify the specification is to
> add an explicit office:frame (or draw:frame) element and move all the
> "frame" attributes up to it. It's contents then become 1..n of the
> existing "frame" elements
> (text-box,image,applet,plugin,object,object-ole) minus all the frame
> attributes. The order of these elements under the office:frame element
> dictates the applications preference for use with the first child being
> the most preferred.
> Notice this not only allows OLE objects to have multiple renditions (the
> primary use case) but other things like plug-ins, applets, etc. to have
> them. This seems a simple and flexible change to me. 

Yes, it's simpler and more flexible.

The only thing I wonder about is that this allows some silly 
combinations. E.g., what's the semantics of a text frame with two 
text-boxes, one containing <text:p>Peter</text:p>, the other containing 
<text:p>Mary</text:p>? Would there be any circumstances in which the 
second gets displayed?

One could try to restrict this in the schema (e.g. allow only one 
text-box child), but my gut feeling is this isn't worth it; these kinds 
of restrictions translate badly into XSD and DTD. So I'd say we keep 
Phil's proposal... we can't keep people from shooting themselves in the 
foot anyway.


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