[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [oiic-formation-discuss] Implementation, Interoperability and Conformance
So how might we add that view to the TC deliverables? We (or some following implementation group) can find out about such incidents as yours. Thats where the knowledge (source of the educational matter) comes from. They can deliver that in some format which I called educational? The Question for the TC remains. How to translate that experience/ knowledge, into some format that end users can get at? Propose a deliverable. A document specifying how compliance tests may be translated into user advice regarding ODF extensions. Yuk. We must be able to do better than that Craig :-) regards On 28/06/2008, Craig A. Eddy <tyche@cox.net> wrote: > 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: >> 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 >> >> > -- Dave Pawson XSLT XSL-FO FAQ. http://www.dpawson.co.uk
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]