RE: [oic] deliverable "state of interoperability"

[robert_weir@us.ibm.com]

"Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 01/20/2009 
11:42:52 AM:
> 
> I didn't think of description of *our* state and what we are working
> on/toward is what was intended.
> 
> My thinking was that this would be a way to identify what the
> interoperability hot spots are so that there could be focused, 
prioritized
> attention on those areas where interoperability improvement is important 
to
> users of ODF-supporting applications.  We need some grounded assessment 
that
> allows us to focus our limited resources on what matters the most for 
ODF
> interoperability and conformance.
> 

When I was drafting the charter text I intentionally wrote the TC would "
Initially and periodically thereafter, to review the current state of 
conformance and interoperability among a number of ODF implementations". 
The idea was for this to be a regular (periodic) activity where we report 
on the state of interoperability and hopefully indicate what progress has 
been made.  Obviously, in our first report this will be more of a baseline 
indication, since the OIC TC has not yet improved interoperability.  But 
we could certainly indicate other activities in the area, reports, common 
complaints, etc.  I was not thinking that these reports would 
pre-requistite us running an interoperability test suite.   We need to 
bootstrap the process based on information that already exists. 
Note also that the date in the charter is arbitrary and the TC is free to 
agree to adopt another date if it wishes. 

> There is the question about how we identify the state of 
interoperability,
> and although you, I and everyone else has our own hot buttons, I am not 
sure
> that is what matters most.
> 

The report can certainly express a consensus opinion of the TC for what 
priority areas are.  However, since we do not have results of a 
comprehensive test suite to go on, any of our opinions will be based on 
personal experience, anecdotes and a handful of smaller test cases, e.g., 
the Rajiv Shah tests.

> It strikes me that to do this well we need a way to gather inputs from
> concerned parties about where there are concerns over missing
> interoperability in real-world practical settings.  We want some 
visibility
> on those cases where limitation is an immediate problem and a barrier to
> adoption of ODF supporting products.
> 

OK.  We have a few people on the TC who represent large organizations who 
are deploying ODF internally, such as Bart/Fedict, Michael/Sun, 
Aslam/South Africa, me/IBM, etc.  That is the most immediate source of 
information.  I'd start there.

> There must be a way to do this with organizations that have taken the
> initiative in adopting ODF and have experience in product 
interoperability.
> Vendors might have information they can share in regard to what comes in 
as
> hot spots from adopters of their products, but we should not depend on 
that
> as a sole source. 
> 

Well, where a vendor is also a deployer, that then becomes a valid data 
point, equally as valid as any other deployer.  I certainly wouldn't 
disregard an ODF deployer's views simply because they happen to also be a 
vendor.

> Perhaps all that might happen for March is reporting on how we are going
> about this and perhaps some early indications. 
> 

The date is flexible, as mentioned earlier.  I'm hoping we can go beyond 
restating the charter or our road map.  I'm hoping we can actually say 
something about the state of interoperability today.  Think of it this way 
-- How do we gauge our success?  How do we prove to someone that we 
actually accomplished something?  Giving a baseline report of 
interoperability and then periodically reporting on progress is a key part 
of this.  But certainly developing a road map is an aspect of progress. 
Planning is step #1.

> Having a corpus of representative documents where interoperable use 
fails is
> good too, although we need to make sure the documents of that kind are
> important in someone's interoperability situation and not marginal cases 
in
> practice.
> 

An example file or a few might give some color to the discussion of the 
state of interoperability.  Maybe one step is to define some taxonomy for 
interoperability problems and then remark on the impact and prevalence of 
each in ODF applications today?  Even for our own internal use we would 
certainly benefit from a shared vocabulary for describing interoperability 
issues.

> Does this make more sense of that aspect of the Charter? 
> 
> Rob, as the principle author, has more light to shed on this.  My
> appreciation was inspired by the discussions in formulating the charter, 
but
> all extrapolations and misunderstandings are mine.
> 
>  - Dennis
> 
> -----Original Message-----
> From: Hanssens Bart [mailto:Bart.Hanssens@fedict.be] 
> Sent: Tuesday, January 20, 2009 04:29
> To: oic-list
> Subject: [oic] deliverable "state of interoperability"
> 
> Dear members,
> 
> 
> Per charter, we should create a "state of the interoperability" report
> by the first of March. 
> 
> My first idea was to use the whitepaper template, but as Mary pointed me
> out, a "specification" is currently the only sanctioned format (with
> another category "informational documents" on its way) so the
> specification template is preferred.
> 
> 
> If no-one volunteers, I'm willing to write a first working draft with
> - some of my own observations
> - references to related efforts
> - a few simple scenarios for creating a few test documents to highlight
> some issues (for example: the infamous table in table construction)
> 
> (say, by the end of the month)
> 
> Of course, every TC member is encouraged to contribute to this report
> and add or rewrite sections
> 
> 
> With those scenarios, I would like a few volunteers (vendors /
> developers, this could be you ;-) to
> - create test documents in various implementations
> - contribute them to the OIC TC
> - see what happens when opening/editing these docs in another
> implementation
> 
> (say, by mid-Februari)
> 
> Then, we can finalize the report and organize a vote to make it a
> "committee draft"
> 
> While we won't be mentioning product names in the report, it's
> inevitable that we'll have some discussion along the lines of "X does
> foo, Y does bar" on the list.
> 
> 
> 
> So, How does that sound ?
> 
> 
> 
> Best regards,
> 
> Bart
> 
> 
> PS: this does not mean you shouldn't be working on the analysis of the
> ODF package (http://wiki.oasis-open.org/oic/SpecAnalysis), it's
> additional homework ;-)
> 
> 
> ---------------------------------------------------------------------
> 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 
> 
> 
> ---------------------------------------------------------------------
> 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 
>