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 Law of UnintendedConsequences

On 01/19/09 22:29, Dennis E. Hamilton wrote:
> One more thing about floor=ceiling.  
> Later, not realizing the connection to the floor=ceiling case until now, I
> took on as an architectural practice for interfaces and specifications that
> it is always easier to relax a restriction later than it is to later
> restrict a relaxed definition.  When I am in a quandary over some provision,
> this is always a valuable tie-breaker for me.  (I call this the Wilson
> Principle for Richard Wilson, an internal-systems architect at Xerox in the
> 70's.)
> We find ourselves facing the second situation, not the first, and we have a
> number of "extension" points baked in.  We will have to decide what we will
> do, normatively, about the 1.2-ness of scripts in languages specified by a
> QName prefix, table formulas (ditto), defined extension provisions in the
> repertoire of formula functions, etc.

Well, actually we have decided this already with the approval of ODF 
1.1, and/or proposals we have accepted that change anything in this 
area. So, unless a TC member proposes a change to one of the many 
extension points we have, things stay as they are. At least, my 
conformance proposal does not touch any other extension mechanism than 
foreign elements.

We are discussing foreign elements because they a) were part of the 
conformance clauses we need to refine, and b) because with the meta data 
features two main arguments for having them (embedding on non-ODF 
information, extension of metadata) have disappeared. I think we should 
limit the discussion to this feature. We may discuss specific 
adjustments to other extension areas, but I think we should do so 

Best regards


> By the way, I have no objection to conformant being tightly defined,
> although honoring the strict schema by itself won't do the job we think it
> accomplishes, depending on how the above things are accounted for in the
> schema (I don't know), and how things like binary sub-files having vnd.*
> MIME types are to be accounted for.
> It may be that loosely-conformant is the wrong term, but neither conformant
> nor loosely-conformant, at the moment, determine whether interoperability
> will be easy or hard.  What I like about loosely-conformant is that it
> provides that there be a conformant document in there, given certain
> adjustments.  (There are also some edge cases that one might worry about,
> where dropping an attribute means there is no attribute in a way that
> impairs the document, table cell formulas being an interesting case.  This
> condition only works well for ODF 1.2 because of its completeness with
> OpenFormula.  This is an argument for recognizing those cases as
> loosely-conformant, but it is not my ox that gets gored if only the
> OpenFormula case qualifies in a conformant spreadsheet document.)
>  - Dennis
> -----Original Message-----
> From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
> Sent: Monday, January 19, 2009 10:45
> To: robert_weir@us.ibm.com
> Cc: office@lists.oasis-open.org
> Subject: RE: [office] ODF 1.2 Single-Level Conformance and Law of Unintended
> Consequences
> This also reminds me of another debate, called floor=ceiling.  
> Floor=Ceiling was debated in the early days of initial COBOL standardization
> efforts and it continued for a while.  I can't recall which side of the
> debate Committee Chair Howard Bromberg held onto and if he flipped at any
> time.  
> Generally, producers of implementations did not look kindly at floor=ceiling
> and user communities (but not all of them) and especially standards sheriffs
> of various persuasions wanted floor=ceiling.  Of course, COBOL was
> modularized and there were definite implementation-specific provisions
> (COMPUTATIONAL-1, COMPUTATIONAL-2, ... and similar aspects coming to mind),
> so I am not sure how much it was felt that floor=ceiling was achieved, in
> the end.   
> [ ... ]
> ---------------------------------------------------------------------
> 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 

Michael Brauer, Technical Architect Software Engineering
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
	   D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering

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