Re: [office] Proposal: To add default value for draw:auto-grow-height,draw:auto-grow-width,fo:wrap-option,style:flow-with-text

[Zhi Yu Yue <yuezhiyu@cn.ibm.com>]

Hi Michael,

I now understand the reasons not to
define the default values, but the problem of interoperability and ambiguity
below still exists. I believe that some other attributes may have similar
problems. Did we get some good way to solve this? Thanks!

Best Regards,
Helen Yue(Zhi Yu)

From:	Michael Brauer <Michael.Brauer@Sun.COM>
To:	OASIS Office <office@lists.oasis-open.org>
Date:	09/06/2007 07:45 PM
Subject:	Re: [office] Proposal: To add default value for draw:auto-grow-height,draw:auto-grow-width,fo:wrap-option,style:flow-with-text

---

Hi,

it is even more difficult. Within styles, formatting properties that are
not set in a specific style are inherited from the parent style. I'm not
sure under which circumstances an a:defaultValue attribute is evaluated
by a parser. But if a default value is specified by an a:defaultValue 
attribute within a style, and if it is evaluated, then this entirely 
breaks the inheritance feature, because every style then defines all 
formatting properties and assigns the default values to them. Formatting
properties defined in parent styles won't be evaluated any longer.

That's actually the reason why for no formatting property, an 
a:defaultValue attribute is specified.

Another difficulty for specifying default values on the schema level is
that formatting properties are re-used for different kind of objects and
style families, and that their default they may differ for the different
document types. The default margin of a paragraph style (that it is 
applied to a paragraph) may for instance be different than that of a 
graphic style (that is applied to the geometry of the drawing shape), 
and the default font size may differ between text and spreadsheet document.

A basic feature of ODFs style inheritance model are default styles 
(section 15.2). They allows to specify default values for each style 
family, that then apply to the full document. So, if one wants to make
sure that a certain formatting property has a certain default value, 
then this is possible already by specifying it in the default style. 
However, for formating properties for which no default is specified in
the default styles and styles of a document, a user or application 
defined value is used. This on the one hand allows to leave it open by
intention which value is used, what may be actually reasonable for 
properties that are often user defined or system depended (for instance
font names and sizes, or for the paper size). But on the other hand this
means that applications may use different defaults.

If we want to provide more guidance what typical user settings or 
application defaults are, I could image that we provide (informative) 
sample or (normative) reference default stylesheets in the form of ODF
fragments (or separate ODF documents?), or that we add (informative or
normative) tables which list the default values for those properties, 
for which reasonable defaults can be specified.

I think we should have a deeper look into this on the next con call.

Best regards

Michael




Bruce D'Arcus wrote:
> Zhi Yu Yue wrote:
> 
>> The following proposal aims to add default value for several 
>> attributes in the graphic properties, respectively "fo:wrap-option",
>> "draw:auto-grow-height", and "draw:auto-grow-width".
Currently, there 
>> is no default value defined for these attributes. It will cause
>> ambiguity when there is no such property specified in the 
>> graphic-properties. 
> 
> I'd be careful about relying on default values. RELAX NG does not
-- by 
> design -- include formal support for default values. To quote James
> Clark [1]:
> 
> "9. Another problematic area in W3C XML Schema is the support
for
> infoset augmentation, such a default attributes.  Experience
with XML
> 1.0 has, I believe, shown that this is not a good feature to include
> in a schema language.  Apart from being a violation of modularity,
it
> tends to cause interoperability problems, because it leads to the
> possibility of the application getting different information depending
> on whether or not validation has been performed.  RELAX NG, by
> contrast, never changes the information that an application receives.
> It specifies purely what is valid and what is invalid."
> 
> Maybe it's not an issue here, but just wanted to point it out.
> 
> Bruce
> 
> [1] <http://www.imc.org/ietf-xml-use/mail-archive/msg00217.html>


-- 
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH             Nagelsweg
55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice
        +49 40 23646 500
http://blogs.sun.com/GullFOSS

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
        D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering