RE: [office] <style:default-style>, <style:default-page-layout>

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

1. Andreas: It is indeed the case you raise that I had in mind.  If a
"default" is explicit in the file, put their by the generating application,
we are fine.  When the generating application does not do that, and the
consumers each have their own approach (the implementation specific value)
that is taken silently, that is the problem.

2. Patrick: With regard "there isn't any 'otherwise an implementation
specific value is taken.'"  I don't understand.  I am looking directly at
the second full paragraph of 15.2 in cd01 rev06 and the statement is right
there.  It is also there in cd02, approved since my original remark.  So the
statement is there.  So what is it you are saying there isn't one of?  What
do you think that sentence means?

 - Dennis

-----Original Message-----
From: Andreas J. Guelzow [mailto:aguelzow@math.concordia.ab.ca] 
Sent: Friday, May 22, 2009 13:58
To: office@lists.oasis-open.org
Subject: Re: [office] <style:default-style>, <style:default-page-layout>

On Fri, 2009-05-22 at 16:46 -0400, Patrick Durusau wrote:
> Dennis,
> 
> Just now getting to this in my effort to clear editorial notes.
> 
> Note from 15.2, the language you cite:
> 
> > "If a value for the formatting property has not been found, then the
default
> > style (see 15.3) that has the same family as the style that has been
> > referenced initially is checked. If it specifies a value for the
formatting
> > property, then this value is taken. Otherwise an implementation specific
> > value is taken."
> There isn't any "otherwise an implementation specific value is taken."
> 
> By definition the "default" style is defined by the implementation.
> 
> Unless you think we are saying:
> 
> 1. Defined styles
> 
> 2. Default style (defined by the application)
> 
> 3. Application specific value but not as part of a style definition.
> 
> I am not sure I see #2 and #3 as being different, except that we do 
> refer to default styles belonging to families.
> 
> I do agree that what you say is a way out, although it isn't the way I 
> would prefer. My preference being, perhaps in ODF-Next, to define styles 
> so that some similarity in appearance can be had across conforming 
> implementations. Appearance really has very little, in my view, to do 
> with interoperability but that viewpoint has not carried the day. ;-)
> 

Hi,

I think that you may be missing the point that there may be 2
implementations involved. So we have the following list of priorities:

1. defined style
2. default-style contained in ODF file (and apparently put there by the
implementation that created the file. That default style may originally
been implementation dependent but has now been fixed for this file.)
3. default style not contained in the ODF file that depends on teh
implementation reading/displaying the file.

Andreas

> 
-- 
Andreas J. Guelzow, PhD, FTICA
Coordinator, Mathematical & Computing Sciences
Concordia University College of Alberta


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php