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: Re: [oiic-formation-discuss] Implementation, Interoperability and Conformance


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]