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


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

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]