[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [oiic-formation-discuss] Implementation, Interoperability andConformance
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.
Dave Pawson wrote:
firstname.lastname@example.org" type="cite">2008/6/28 Craig A. Eddy <email@example.com>: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 someother file format are out of line, outside the scope of this discussion, and off topic.+1 regards