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

 


Help: OASIS Mailing Lists Help | MarkMail Help

oic message

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


Subject: interop profile or interop advisories ?


Hi,


Since there are some concerns about the  scope of the interop profile (in scope of the OIC
TC charter or not) and the current all-or-nothing approach, I have another proposal (also
mentioned during today's call).

Instead of one big document, we could create very specific "Interop Advisories", not unlike
the "CERT advisories" on security issues or the PDF/A competence center's Technical
Notes (see also http://www.pdfa.org/doku.php?id=pdfa:en:techdoc)
 
An Interop Advisory could (more or less) look like this:

*****

OIC INTEROP ADVISORY 00001 - 01 JUNE 2010

* SPECIFICATION: 

ODF 1.1,  4.6 Change tracking

* AFFECTS:
ODF Consuming office applications not supporting change tracking

* DESCRIPTION:
Upon reading an ODF document containing tracked changes, some ODF Consuming
office application that do not support change tracking display the contents of the 
<text:tracked-changes> element. This may confuse and/or annoy end user.

* RECOMMENDATION

Producers: N/A

Consumers: ODF Consuming office applications that do not support change tracking are
advised not to show the contents of <text:tracked-changes> element 

****

Optionally, we could provide one or more very simple test documents so developers could
quickly check if their implementation is affected or not.


The idea would be that the OIC agrees on the recommendation (by e-ballot) and that the
advisory is to be stored in the OIC document repository. Every X months, a "catalogue"
could be produced (including cover pages etc) containing the advisories of the last X
months, voted upon by the OIC, submitted to the TC admin and have it approved as OIC TC
"Specification" without conformance clauses.


Important to note:

- this advisory will not contain names of implementations (although even a casual observer
may sometimes guess what implementations are / are not affected)

- we could add simple example test documents (but I wouldn't like to spend much time on
painfully crafting XML meta-documents with metadata on expected behavior, category etc.
In the ideal world this would indeed be nice, but we are resource-limited)

- there's no real normative text and no implementation deadline, although of course it would
be awkward if TC members would first agree on an interop recommendation and afterwards
decide not to implement it in their products in a timely matter... (for whatever value of timely)



I believe this fits in the last part of item 1 of the OIC charter:

"recommend prioritized activities for advancing the state of conformance and interoperability
among ODF implementations in general without identifying or commenting on particular
implementations;"

and part 6

"To provide feedback, where necessary, to the OASIS Open Document Format for Office
Applications (OpenDocument) TC on changes to ODF that might improve interoperability;"

(in this case the feedback to the ODF TC would be: specify the recommendation in the next
version of ODF)


Benefit: I assume it would be much quicker to agree on a specific interop issue, and I think
it addresses the concerns raised by the TC members, while still be useful for implementers.


Any thoughts ?


Best regards

Bart


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