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>


Dennis,

Sorry it took so long to get back around to this post!

Yes, you are entirely correct, we do need to agree on what the problem 
"is" before we can attempt a solution.

Personally I favor the notion of an ODF specified result for styles. 
While markup "interoperability" means something else, presentation is 
the most common aspect that users will perceive as representing 
"interoperability." Perhaps from their perspective that isn't altogether 
unreasonable. And we are after all trying to craft a markup format that 
meets their needs and not necessarily our appreciation of the finer 
points of markup theory.

I am less certain about simply prohibiting the use of implementation 
values, but I would like to know where our values or value ranges are 
insufficient.

Hope you are having a great day!

Patrick

Dennis E. Hamilton wrote:
> 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?
>
> [ ... ]
>
>
> ---------------------------------------------------------------------
> 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 
>
>
>   

-- 
Patrick Durusau
patrick@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)



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