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] Proposal: To add default value fordraw:auto-grow-height,draw:auto-grow-width,fo:wrap-option,style:flow-with-text


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


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
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500

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

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