OASIS Open Document Format for Office Applications (OpenDocument) TC

 View Only
  • 1.  RE: [office] ODF 1.2 Single-Level Conformance and Floor << Ceiling Already

    Posted 01-19-2009 23:19
    Rob,
    
    I recalled the floor=ceiling debate as the kind of thing that has plagued
    standards bodies from olden times, yet I completely misremembered the
    dimensions of the debate.  I noticed that as I was sending off the note
    about MIMETYPES and how 


  • 2.  RE: [office] ODF 1.2 Single-Level Conformance and Floor << Ceiling Already

    Posted 01-19-2009 23:47
    I forgot something, if I want to make an application/xml document (and
    whether this is required and what else is permitted, like a 
    is a bit vague in the ODF specifications, since the XML specification allows
    both and requires neither):
    
    	-	-	-	-	-	-	-
    
    
    
    
     
    
    	-	-	-	-	-	-	- 
    
    


  • 3.  Re: [office] ODF 1.2 Single-Level Conformance and Floor << CeilingAlready

    Posted 01-20-2009 13:06
    On 01/20/09 00:46, Dennis E. Hamilton wrote:
    > I forgot something, if I want to make an application/xml document (and
    > whether this is required and what else is permitted, like a 
    > is a bit vague in the ODF specifications, since the XML specification allows
    > both and requires neither):
    
    
    If the XML specification allows both and requires neither, you can use 
    neither or both. Why should the ODF specification be more specific than 
    the XML specification? What problem would that solve? Or, what is the 
    issue with not being more restrictive than XML itself?
    
    Michael
    
    
    
    
    > 
    > 	-	-	-	-	-	-	-
    > 
    > 
    > 
    > 
    >  
    > 
    > 	-	-	-	-	-	-	- 
    > 
    > 


  • 4.  RE: [office] ODF 1.2 Single-Level Conformance and Floor << Ceiling Already

    Posted 01-20-2009 16:43
    The XML specification makes it clear that variations are relevant to the
    application of XML that is in hand.  There is nothing wrong with simply
    saying all of XML is tolerated, but one probably needs to say so explicitly.
    
    For example, is handling of encodings other than UTF8 and UTF16 (with
    however byte-order is handled in that case) required to be supported and
    which is part of strict conformance and which is not?  That impacts what can
    be said in IRIs, for example, and how they have to be encoded to pass
    through the particular character-set encoding.
    
    The key is whether the XML specifications areas of mandatory, optionality,
    and variability have been explicitly considered and whether there are
    qualifications in the specific case of the XML in the structure of ODF
    documents.  It is always a concern whether that is not explicitly accounted
    for in a derivative use, because it is not clear what might simply be an
    oversight.
    
    This might seem fussy, but it is valuable to be explicit and to avoid the
    risk of unintended consequences for both conformance and interoperability.
    
    Being specific about the specification version that is relied on as a
    normative reference matters too.  For example, the current edition of XML
    1.0 has a much broader definition of the characters usable in Name and
    NCName values.  It might be a surprise in the implementation of ODF
    1.0/1.1/1.2 to find that these are now legitimate.  (This has to do with a
    breaking changed in creation of the current edition, a change that has been
    forced through xml:id by reference too.)
    
     - Dennis
    
    


  • 5.  RE: [office] ODF 1.2 Single-Level Conformance and Floor << Ceiling Already

    Posted 01-20-2009 13:59
    This is irrelevant to the topic at hand, I believe.  If I'm reading you 
    correctly (and maybe I'm missing something) you are arguing that we should 
    not bother fixing this area of ODF because there are other parts that are 
    also poorly written. But the fact that there are other areas which need 
    conformance work in ODF is not incompatible with concerns about ODF's 
    current open content model.  The inability to do everything is no excuse 
    for doing nothing.  IMHO, we should fix this and the other things too. 
    Maybe you could start a Wiki page with other such areas where you have 
    conformance concerns with other areas?  Some of these other areas could 
    also be addressed.  For example, Appendix D could be made normative with 
    the introduction of  conformance classes for "ODF Text Consumer", "ODF 
    Spreadsheet Consumer", etc., to set a floor for that functionality.
    
    And remember, no change worth making to tighten conformance will be 
    without some amount of pain.  We're not dealing with a standard that 
    existing first and then a number of applications freshly written to 
    implement it. We're starting with several applications all who wish to 
    converge on an interoperable document format, but have started from 
    slightly different starting points.  The goal is not to award the label of 
    "conformant" to the maximum number of parties possible.  The goal is to 
    improve interoperability.This is similar to the C++ programming language, 
    where there was already a degree of divergence in functionality before 
    standardization began.  But they did not solve this by having "loose C++" 
    which encompassed everything and "strict C++" which had just what the 
    committee really wanted.  They had C++ period, and implementations, over 
    time and some much slower than others, converged on the standard. 
    
    -Rob
    
    "Dennis E. Hamilton" 


  • 6.  RE: [office] ODF 1.2 Single-Level Conformance and Floor << Ceiling Already

    Posted 02-03-2009 23:24
    I think messing with the ceiling doesn't accomplish anything.  Doing
    something about the floor matters far more for the achievement of
    interoperability and will have more bang for the buck.  
    
    Whether it takes more work or not, I am not sure, but I think that is much
    more valuable to invest in than the current effort to lower the ceiling.  
    
    I also think that having a strict schema and strict conformance as a
    normative case (separate from the ceiling) will do far more as a single step
    than anything about the ceiling.
    
    I do not propose to do nothing. I propose to do something where it will do
    the most good and be the simplest direct improvement we can make without
    breaking the provisions of earlier versions that were apparently made quite
    intentionally.  I don't think we should revoke that provision until we have
    had time to see how strict conformance and greater support for
    interoperability work out.
    
     - Dennis 
    
    


  • 7.  RE: [office] ODF 1.2 Single-Level Conformance and Floor << Ceiling Already

    Posted 02-04-2009 00:49
    "Dennis E. Hamilton" 


  • 8.  RE: [office] ODF 1.2 Single-Level Conformance and Floor << Ceiling Already

    Posted 02-04-2009 04:47
    Rob,
    
    I did not confine my observations to documents existing today.  I don't know
    that there are any problems with documents existing today (e.g., ones that
    are identified as conforming to ODF 1.0/IS 26300/ODF 1.1).  I think the
    interoperability problems we face today are with the consumers and
    producers, not the documents as far as I know.  
    
    My considered opinion is that lowering the ceiling is irrelevant with regard
    to the improvement of interoperability at least out through the life of ODF
    1.2 and probably beyond (say, not until ODF 2.0 or somesuch).  Furthermore,
    most of the situations that I find interesting are neutral with regard to
    interoperability when implemented with full knowledge of default foreign
    element-attribute-value treatment.  (I am itching to discuss what I see as
    fruitful use of this mechanism, but I don't think it matters with regard to
    the key question.)
    
    Furthermore, I do not anticipate a flood of proprietary extensions to ODF
    1.2 documents.  
    
    But whether or not you share my sense that we can expect continuing good
    will among (competing) producers for addressing serious user-community
    demand for interoperable and reliable implementations of ODF, I think there
    is a bigger issue.
    
    I take this as a promise:
    
       "Documents that conform to the OpenDocument specification
        may contain elements and attributes not specified within
        the OpenDocument schema. Such elements and attributes must
        not be part of a namespace that is defined within this 
        specification and are called foreign elements and attributes.
    
        "Conforming applications either shall read documents that 
        are valid against the OpenDocument schema if all foreign 
        elements and attributes are removed before validation takes
        place, or shall write documents that are valid against the 
        OpenDocument schema if all foreign elements and attributes 
        are removed before validation takes place.
    
        "Conforming applications that read and write documents may 
        preserve foreign elements and attributes."
    
    I do not see any reason to break a promise when there has been no difficult
    with it and it has been through three rounds of standardization, two at
    OASIS and one at ISO/IEC JTC1.  I can't imagine that this provision failed
    to be noticed.  Also, considering the work there is to make ODF 1.2 as good
    as an ODF 1.2 that there can be with the means available, I see fussing with
    this as unnecessary breaking of something that does not appear to need
    fixing, especially since making strictly-conformant documents part of the
    normative specification provides a solid place for procurement
    specifications and selection of products by those who are now allergic to
    this provision.
    
    This promise has been on the books for a healthy period of time.  I don't
    know what led to its being made, but it has been noteworthy all along.  As
    far as I am concerned, it has neither helped nor hindered the achievement of
    interoperability among ODF implementations.  But it is a promise.  
    
    Whatever reconsideration that seems to be on the current agenda, I must
    assume this promise was not made lightly and that we should avoid its
    revocation without serious cause.  I do not believe there is any such cause
    in evidence and we should let the precedent stand.
    
    I also expect that any suspected perpetrations under this provision will be
    noticed and objected to in broad public forums and any promulgation of
    specific foreign elements-attributes-values will receive careful scrutiny.  
    
     - Dennis
    
    PS: There is a degree to which the above statement from ODF 1.1 is a little
    underspecified. That is not unique to this passage and we might look into
    addressing that so any benign use of this provision is done safely and with
    attention to the consequences of the way foreign elements may be processed
    by implementations that do not recognize them.  There are some aspects of
    that in Michael's proposal.  I'm all for that.
     
    
    


  • 9.  RE: [office] ODF 1.2 Single-Level Conformance and Floor << Ceiling Already

    Posted 02-04-2009 19:25
    I must correct this flawed analysis.
    
    OASIS is very clear about what kind of changes can be made to revisions of 
    a standard.  In particular, Approved Errata may not contain Substantive 
    Changes, where "Substantive Change" is defined as "a change to a 
    specification that would require a compliant application or implementation 
    to be modified or rewritten in order to remain compliant".
    
    However, there is absolutely no prohibition against making a Substantive 
    Change in a new version of an OASIS standard.  This is 100% legitimate 
    from OASIS, ODF TC and even ISO rules.  (Heck, ISO would even allow 
    breaking changes in Corrigenda, so they are even more permissive in this 
    regard).
    
    So the only "promise" is with regards to the ODF 1.0 and ODF 1.1 
    standards.  OASIS will not allow us to change conformance there.  But we 
    have full ability, under the rules, to make any change we wish in ODF 1.2. 
    
    
    Now, if the ODF TC wishes to adopt a Standing Rule that sets out some 
    additional guidelines for what kinds of changes will be made in what kinds 
    of release, a major/minor scheme, a schedule of deprecation, etc., it has 
    full authority to do so, provided it doesn't contradict OASIS rules.  But 
    unless there is consensus to adopt such standing rules, we are 
    unrestricted in how we change conformance in ODF 1.2, so long as the 
    clause itself otherwise meets OASIS requirements. 
    
    I want to make sure that this process question is clear to every TC 
    member.
    
    -Rob
    
    "Dennis E. Hamilton" 


  • 10.  RE: [office] ODF 1.2 Single-Level Conformance and Floor << Ceiling Already

    Posted 02-04-2009 20:07
    Rob, I do not question what an OASIS TC is permitted to do, although it is
    strange to do it with regard to a .-release.
    
    I am thinking of this as a moral obligation, not a technical one.  While we
    may make substantive (breaking) changes, that does not mean we should in a
    particular case, and that we should be serious about avoiding them unless
    there is some serious technical problem to be dealt with.  I will continue
    to regard it the defined conformance level as part of a social contract with
    the ODF community (users and implementers) and all of the promotion that has
    accompanied the advent of ODF.
    
    I said "I take this as a promise."  That's a declaration on my part.  I was
    not implying anything more than that other than we have set a level of
    expectation that has been reaffirmed with three full-blown standards review
    and approval processes, and that I see that to be taken seriously in the
    pursuit of the promise of ODF.
    
    Also, if I thought it was something that we were technically bound to, I
    would be objecting that we are violating OASIS rules or our own standing
    procedures rather than continuing to participate in the discussion of
    Michael's proposal as a proper proposal.
    
     - Dennis 
    
    PS: I do think the ODF TC *should* declare itself with regard to how it
    regards up-down-level compatibility, preservation of the usability of legacy
    documents as processors move to implementation of later versions, etc.
    Considering what ODF is promised for with regard to use in civic affairs,
    governmental operations, and other places where long-term usability is a
    great concern, I would think that is an important detail to affirm.