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] <style:default-style>, <style:default-page-layout>


Patrick,

1. CLARIFICATION

  1.1 I think we are being confused between (1) the technical use of
"default-" in the ODF specification for an explicitly-expressed provision in
the ODF format versus (2) an implementation-specific value that is not in
evidence but that is employed invisibly in the absence of an
explicitly-expressed provision (whatever its origin).  To be precise, I will
not here use "default" in any sense but in the specialized technical sense
(1) of the ODF specification, and use implementation-determined for case (2)
and its kin.  

  1.2 The question at hand is whether it is supportive of interoperability
to have case (2) in 15.2 or whether there should be an ODF-specified result
instead of an implementation-determined one, at least for the more-specific
conformance targets that are introduced with ODF 1.2.  (Another way to deal
with this would be to declare a document invalid if it depends on a
formatting property for which a value is not explicitly determined in the
document, without any resort to implementation-determined values.) 

2. ANALYSIS

  2.1 My reading of the sentence at the end of the second paragraph of
section 15.2 is about case (2), not case (1).  The ODF specification is
appropriately-silent on how instances of case (1) arise in the
representation of an ODF document (that is, whether they are introduced
automatically by a processor and/or whether an user may influence and even
specify them).  Case (2) applies when there is no such resolution under (1).

  2.2 My reading of section 15.2 on <style:style> is that it specifies how
the value of a formatting property is determined in a context where such a
value is required.  If the described hierarchic search fails to yield a
value for the particular formatting property, the *optional* default styles
provided *explicitly* in <style:default-style> elements are consulted.  If
the applicable and explicitly-provided default styles (if any) also fail to
yield a value for the formatting property in question, then 15.2 tells us
that "an implementation specific value is taken."  [NOTE: Since
<office:styles> and all elements in it are entirely optional in accordance
with the schema, it appears to be conformant to have a document of any type
in which all applicable formatting properties are resolved to
implementation-determined values, absent any constraints specified separate
from the schema -- I haven't gone looking.] 

  2.3 It is this injection of a magical implementation-determined value that
is in question, since different implementations can determine quite
different values.  One needs to consider whether this is conducive to
interoperability.  [I suppose it might also be valuable to check whether
[CSS2] and [XSL] collide with this in any way.]

3. POTENTIAL RESOLUTION

  3.1 I appreciate that the resolution of this question is not obvious.
Considerations for allowing an implementation-determined value have been
presented in justification of the current language.  I can also see this
happening in custom-use situations.  If this allowance for
implementation-determined values is retained, it would seem that we need to
look at the conformance clause that it fits with.

  3.2 My intention here is for there to be an agreed understanding of what
the question *is*.  If we are able to do that, we can then determine (a)
whether we want to allow the language to remain or (b) whether there is a
more-interoperable requirement that would apply to conforming documents or
at least the conforming-document cases being introduced in 1.2 for the
specific document types.  

  3.3 Since it would seem too difficult to specify fixed formatting property
values for all cases where the value is not determined in the ODF document
markup, I suspect that dependence on implementation-determined values should
simply be prohibited in the conforming document-type cases.  Having
formatting properties always have explicitly-determined values seems to be
an appropriate prerequisite for that level of document conformance.  But we
can consider that once we agree what the problem and the question are.  The
resolution may not be so obvious as it appears to me from my single
viewpoint.


4. SUPPLEMENTAL OBSERVATION ABOUT ODF NOMENCLATURE

  4.1 The spelling "stylesheet" is only used twice in ODF 1.2 cd02.  Both
occurrences are in the context of XSL and XSLT, one in the first bullet of
section 16.1 and again in the title of the [XSL] bibliographic reference.  I
suppose that 16.1 should say "XSL stylesheet" instead of "XSLT stylesheet"
to be more precise.  

  4.2 Section 16.1 can be read as also referring to stylesheet in the
context of [CSS2] as well although "style sheet" is used in that title in
the ODF 1.2 cd02 text.  Although there are numerous other references to
[CSS2] in the specification text, none are accompanied by either spelling of
"stylesheet." 

  4.3 None of the three occurrences of either "style sheet" spelling in ODF
1.2 cd02 are in the context of "default stylesheet."  Whatever a default
stylesheet might be, it seems to me that is not what 15.2 is talking about
and the phrase is never used anywhere in the ODF specification.  The related
section 15.3 is about explicitly-appearing <style:default-style> elements in
an <office:styles> somewhere.

  4.4 Although it makes for stilted writing to use a rigid,
explicitly-enumerated technical nomenclature, I believe this discussion, and
the situation around it, demonstrates precisely why standards authorities
find strictly-adhered-to explicit nomenclatures to be essential. 

 - Dennis

-----Original Message-----
From: Patrick Durusau [mailto:patrick@durusau.net] 
http://lists.oasis-open.org/archives/office/200905/msg00118.html
Sent: Saturday, May 23, 2009 03:00
To: dennis.hamilton@acm.org
Cc: office@lists.oasis-open.org
Subject: Re: [office] <style:default-style>, <style:default-page-layout>

Dennis,

Dennis E. Hamilton wrote:
http://lists.oasis-open.org/archives/office/200905/msg00116.html
[ ... ]
> 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?
>
>   
Note questioning the presence of the sentence but how to distinguish 
between a "default stylesheet" (which is simply some implementation 
defined set of values, not a stylesheet in the sense we define them in 
ODF) versus "an implementation specific value..." How are those different?

Both are determined by the implementation.

Neither one is confined by the styles we define in ODF.

We go to some lengths to define stylesheets, how they are referenced, 
their values, etc.

What part of those definitions are applicable to "default stylesheets?" 
So far all I have found is the reference to "default stylesheets" having 
a style family name. They are not defined as part of the document but as 
part of the implementation. (Or so I have been told.)

Then my question becomes how is that different from "an implementation 
specific value?" Seems to me that all an implementation defined 
stylesheet can be is a set of "implementation specific values." Yes?

[ ... ]



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