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] ODF 1.2 Single-Level Conformance and Floor << Ceiling Already


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.
 

-----Original Message-----
From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com] 
http://lists.oasis-open.org/archives/office/200902/msg00042.html
Sent: Tuesday, February 03, 2009 16:50
To: office@lists.oasis-open.org
Subject: RE: [office] ODF 1.2 Single-Level Conformance and Floor << Ceiling
Already
"Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 02/03/2009 
06:23:34 PM:
http://lists.oasis-open.org/archives/office/200902/msg00040.html
> 
> Please respond to dennis.hamilton
> 
> 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,

I'll agree with you on this.  No document existing today will see its 
interoperability improved by this conformance change.  In fact, no ODF 
document will see its interoperability improve by any change made in ODF 
1.2.  Why?  Because all documents that exist today are based on ODF 1.0, 
ODF 1.1 or draft versions of ODF 1.2.  ODF 1.2 cannot retroactively change 
existing documents. 

However, the proliferation of arbitrary proprietary extensions in ODF 1.2 
documents, if and when they occur, will certainly create even greater 
interoperability problems.  I don't see how you can fail to acknowledge 
that.  Your counter argument seems to be "Don't bother locking the gun 
case because there are knives everywhere".  To that I'd say, let's lock 
the gun case and put the knives away safely.  Certainly doing one without 
the other does not accomplish everything, but we need to start somewhere 
and every bit helps.   I haven't heard a plausible argument from you on 
what harm is caused by disallowing arbitrary extensions in conformant 
documents. 

-Rob


[ .. ]



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