Re: [oiic-formation-discuss] Implementation, Interoperability andConformance

["Craig A. Eddy" <tyche@cox.net>]

Dave,
    Being a "teacher's kid", I am well aware of the need for education.  I am also aware that the best form of education comes from actually performing a function and discovering the errors as they come up.  For example, to simplify writing the previous email I used a word processor unsaved document.  That way I had more space available, visually, than was available in the email client, coupled with spell checking and other functions I felt were favorable.  When I copied the text out of the unsaved word processor document and pasted it into the compose window of the email client, I found that many elements from the document did not conform to what the email client was able to use.  Therefore, I had to edit the email, taking out those non-conforming elements by hand.  So, next time I'll know to use a different word processor or text editor for my draft copy, in order to eliminate those elements that the email client is unable to reproduce.  Thus, I was "educated".
    In this way, I used the application itself (the email client) as the test of conformity.  I could have used other tools, had they been available.  But the email client, itself, provided the testing and reported to me, in a pop-up window, that the text did not conform.  This was a built-in function of the email client, and is one application's method of establishing a base-line conformity.  I'm sure other methods can be suggested and achieved.
    ODF is not an application.  I can't just open an ODF application and check that what I have done in application "B" conforms to it.  Therefore, some sort of testing procedure or method would be necessary.  That test, of itself, would be of educational value to both application developers and end users.  It would then be up to the application to either conform with ODF natively, or provide a means of conforming through alternate "save as" methods that did conform.  By the way, had I saved the draft document in a format other than its native format I probably would NOT have run into the problem of editing the email.  So, in effect, I've learned two lessons from the experience.

Craig
Tyche

Dave Pawson wrote:

711a73df0806280955t6b68550bxe13098b77d01360e@mail.gmail.com" type="cite">

2008/6/28 Craig A. Eddy <tyche@cox.net>:

  

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.
    

A solution relevant to this TC.
Education. Let you, the user know what feature list is conformant
(Possibly more useful, that Feature X (from B) is non-conformant)
so that as an author you don't use that, wishing, of course to
bide by the standard.






  

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

Although many users won't care, will simply use the features of either
application
and are likely to distribute non-conformant instances.
  Issue: How to get the information to such users that feature X is an extension
and not to be used?
  Option: Access to PC/IT support staff. Again education seems to be the answer.



  

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.
    

Slight variant possible?
 foreign elements and additions  break interoperability due to their
lack of conformity and therefore ...
Should be recognised, and the tester notified of the existance of such
extensions.

  

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.
    

+1
Normal and effective way to 'grow' a standard.


  

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.
    

+1 in the black and white. Moderated by action needed when resolving shades
of gray :-)


  

 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.
    

+1, with the proviso that we recognise extensions and ident them.


   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.
    

+1


regards