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] Strict Conformance


I have already conceded that strict conformance may not be desirable because
of the other connotations that might be implicit in the term, even if
defined specifically for Strictly Conformant ODF Document.  The following is
just background that I unearthed.

I was curious about exactly what OASIS thought extensions and strict
conformance were, so I did some searching.  

Your [1] came up very high in my search for ("strict conformance" OASIS).
From that I found the OASIS Conformance Requirements for Specifications v1.0
[2], Committee Specification 15 March 2002.  I notice that this document,
among others, is referenced in the current Guidelines to Writing Conformance
Clauses [3].  However, neither extensions nor strict conformance are called
out in the current guidelines.  Also, [2] does not seem to be normative for
[3] and that is worth pondering further at another time.

I see in [2: 8.1.2 Specifying conformance claims] that the only mention of
strict conformance is in this context:

    When a conformance claim is linked to extensions, the term 
    *strict*conformance* is often used. Strict conformance is 
    defined as conformance of an implementation that employs 
    only the requirements of the specification and no more.

I don't quite understand how that works, so I sympathize that using "strict
conformance" might lead to exclusion of more than is intended, especially if
we are not explicit or are uncertain about the extension points that there
are in ODF 1.2. 

It is also useful to see what there is in [2: 8.3 Extensions].

    An extension to a specification is a mechanism to incorporate
    functionality beyond what is defined in the specification. 
    Allowing extensions affects how conformance is defined as 
    well as what conformance claims may be made. Care should be 
    exercised in determining the extent to which extensions are 
    allowed or not allowed. Since extensions can seriously 
    compromise interoperability, specification writers should 
    carefully consider whether extensions should be allowed.

I would also add that the interoperability impacts can depend on the manner
in which extensions are allowed, not just on whether they are allowed or

Here is a clarification of strict conformance that is perhaps more explicit
and explains why we are not going to use it (?) [2: 8.3.1]

    If a specification disallows extensions, then the conformance
    clause SHALL specify that extensions are not allowed and that 
    implementations of the specification SHALL precisely implement
    the complete specification. This is strict conformance. ...
    Note that this prohibition of extensions could be applied to a
    specific profile or level rather than to the entire specification.

The statement for allowed extensions [2: 8.3.2] is also intriguing.  

 - Dennis

[1] Robert Weir.  Re: Caution and Disclaimer on Interoperability.  Response
to Jose Lorenzo on the OASIS oiic-formation-discuss list, 2008-07-12,
available at
[2] Lynne Rosenthal and Mark Skall (eds.).  Conformance Requirements for
Specifications v1.0, OASIS Committee Specification 15 March 2002.  Available
at <http://lists.oasis-open.org/archives/office/200902/msg00069.html> [I'm
embarrassed to report that I had already downloaded this in August 2008,
apparently as part of the run-up to OIC TC formation, or as part of
gathering membership materials, and then forgotten about it.]

[3] OASIS.  Guidelines to Writing Conformance Clauses.  4 September 2007.
Available at

-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
Sent: Thursday, February 05, 2009 15:52
To: robert_weir@us.ibm.com; office@lists.oasis-open.org
Subject: RE: [office] Conformance Clause proposal, Version 8

[ ... ]

It is surprising to hear that the RDF metadata extensions are seen as
extensions of that sort.  I thought we were viewing the RDF metadata
extensions as extensions beyond ODF 1.1 (just as OpenFormula can be viewed
as an extension) and they are not an extension at all in 1.2.  All of the
necessary schema and enabling element and attributes seem to be defined as
part of ODF 1.2.  Maybe we should just call it RDF Metadata from now on and
integrate it into the document model appropriately, even though its
occurrence is optional.  

Is the problem simply that we have been using extension in a different way
than in OASIS parlance and we should simply clean up our nomenclature?

 - Dennis 

-----Original Message-----
From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com] 
Sent: Thursday, February 05, 2009 15:16
To: office@lists.oasis-open.org
Subject: RE: [office] Conformance Clause proposal, Version 8

In OASIS parlance, strict conformance means "conformance of an 
implementation that employs only the requirements and/or functionality 
defined in the specification and no more (i.e., no extensions to the 
specification are implemented).  I'd take that to mean without namespace 
extensions of course, but also without RDF metadata extensions, without 
office:meta extensions, without style:*properties extensions, etc.   It is 
probably worth preserving (or at least reserving) "strict" for that 
designation, even if we don't formally put it in release 1.2. 

Or think of it this way, if we allowed some kinds of extensions in strict, 
then what do we call a document that has no extensions? 


[ ... ]

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:

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