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

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 <>

To:
OASIS Office <>

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          

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