OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

oiic-formation-discuss message

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


Subject: Implementation, Interoperability and Conformance


There are a number of issues facing this list which, in the course of a long and generally uneventful life, I have had to face as an end user.   They can be enumerated as:

  1. Conformity to a common, established file format.   For example the degree to which competing applications adhere to the common and established file format.   Specific examples will not be used, since they are outside the scope of this list, and might tend to confuse the issue in some minds.   There are general or generic cases extrapolated from my experiences which can be addressed.

    1. Premise: A common, established file format that is implemented by two competing applications.  Application "A" conforms to the file format.  Application "B" conforms and extends the file format with its own foreign additions.

      1. Application "A" puts out documents that can be read by any application that follows the file format.   Likewise, application "A" can read the documents of any of those other applications that follow the file format. The applications (and in particular, application "A") conform to the file format.

      2. Application "B", that conforms and extends the file format, puts out documents that can only be completely read by application "B". Other applications attempting to read the documents are unable to parse the data in the extended areas of the format. Likewise, if those other applications save and send the document to the original application, the data in those extended areas is lost. Application "B" does not conform to the file format.

    2. Conclusion: Extending a file format breaks conformity with the format.

  2. Interoperability with a common file format.   For example, the ability of competing applications using the same file format to exchange data.   Again, specific examples will not be used, since they are outside the scope of this list, and might tend to confuse the issue in some minds.   There are general or generic cases extrapolated from my experiences which can be addressed.

    1. Premise: A common, established file format that is implemented by two competing applications.   Application "A"conforms to the file format.   Application "B" conforms and extends the file format with its own foreign additions.

      1. Application "A" puts out documents that conform to the file format.   Likewise, application "A" can read the documents of any of those other applications that conforms to the file format.  Application "A"is able to inter-operate with other conforming applications.

      2. Application "B", that conforms and extends the file format, puts out documents that can only be completely read by application "B".  Other applications attempting to read the documents are unable to parse the data in the extended areas of the format.  Likewise, if those other applications save and send the document to the original application, the data in those extended areas is lost.  Application "B" is unable to inter-operate with conforming applications.

    2. Conclusion:  Extending a file format in such a way that it is non-conforming breaks the ability to inter-operate with conforming applications.

Based on the observations above, the primary importance is the conformity or degree of conformity to which an application adheres.  Foreign elements and additions do not conform to the established file format, and therefore should not be addressed in a Technical Committee tasked with establishing the definition of conformity.  Likewise, foreign elements and additions break interoperability due to their lack of conformity and therefore should not be addressed in a Technical Committee tasked with establishing the definition of interoperability.

Foreign elements MAY be suggested to the appropriate Technical Committee on a case by case basis, and a consensus determined on how to implement such elements such that they become a part of the file format.  However, this is not A Technical Committee much less THE Technical Committee to which such elements may be suggested.

In this instance, the common and established file format is ODF.   This is the file format which applications must implement, and to which applications must conform if they choose to inter-operate with ODF.   That is the base-line.   It is my opinion that attempts to introduce foreign elements into the scope are not part of the purpose of the Technical Committee which we propose.   It is my opinion that attempts to cause ODF to conform to some other file format are out of line, outside the scope of this discussion, and off topic.

Craig A. Eddy
Tyche



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