Re: [oic] interop profile or interop advisories ?

[robert_weir@us.ibm.com]

What would be the audience for this?  it doesn't sound like something that 
end users would get value from.  Maybe implementers? 

We probably want to avoid stating the obvious.  For example, I'll propose 
that the following is obvious:

"Upon reading an ODF document containing Foo, some ODF Consuming office 
application that do not support Foo display the the document incorrectly. 
This may confuse and/or annoy end user."

But there are more interesting, non-trivial cases, perhaps, which are 
worth documenting.

I wonder if the wiki would be a good place for this?  That can be kept up 
to date more easily.

Since a number of ODF implementations release updates 3 or 4 times a year, 
a fixed report can easily get out of date.  The nice thing about CERT 
advisories is they name the exact products and version numbers that are 
impacted, so users can check to see if they are impacted by the flaw.  But 
we can't name products and versions. 

-Rob



Hanssens Bart <Bart.Hanssens@fedict.be> wrote on 05/19/2010 02:19:53 PM:
> 
> 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
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>