Re: [oiic-formation-discuss] Summary and Focus?

[robert_weir@us.ibm.com]

"Dave Pawson" <dave.pawson@gmail.com>
wrote on 06/20/2008 08:03:31 AM:

> 2008/6/19  <robert_weir@us.ibm.com>:
> 
> > Let me give this a try.
> 
> 
> > I don't think the TC will be testing anything, in terms of downloading
> > vendor software, executing tests of it, score and officially
reporting the
> > results.  We're not proposing the creation of a testing
lab or the creation
> > of a certifying lab.  But we are creating assets that could
be used by third
> > party testing labs, or by implementors directly, to evaluate
their
> > conformance to the ODF standard, and to evaluate interoperability
scenarios.
> 
> My term was a test specification. Stating what tests need to be
> carried out. A deliverable.
> (Item 3 below)
> 
> >
> > What I am hearing in terms of deliverables include the following:
> >
> > 1) Researching the state of ODF interoperability today and issuinga
report,
> > with recommendations.  Update this report periodically.
> 
> +1 (bit fluffy Rob? How to firm it up?) - Heavy overlap with 8 below.

I'm open to suggestions.

> 
> > 2) Researching the best practices in profiles, and issuing a
"ODF Profiles
> > Requirements" document
> 
> I'd like the TC to go further than this and define an appropriate
> profiles list.

OK.

> 
> > 3) Creating an "ODF Conformance Test Requirements"
document that details the
> > exact items required to test conformance of an ODF document and
of an ODF
> > application to the ODF standard.
> 
> +1. Clarification. "exact items required" means how each
atomic item
> in the standard
> is to be tested.
> 

I'm thinking that "exact items" means instructions
for how to verify each testable provision of the ODF standard, i.e., all
of the requirements and recommendations.  If we find any non-testable
provisions in the process of creating this deliverable, it would be a defect
in the ODF standard and should be reported to the ODF TC.

> > 4) Creating an ODF Interoperability Test Requirements document
that defines
> > additional tests, including an Acid-like test and other interoperability
> > tests.
> 
> -0 Until clarified. What does this mean? How is it different from
3?
> We haven't come up with a definition of interop, how can we ask for
it?
> Suggest make it broader (as profiles).
> Proposed "Define interoperability between similar ODF applications
> (and documents?)
> and propose suitable tests"

I believe deliverable #1 would logically include a
definition of interop, right?

Probably would just say "interoperability between
ODF applications".  Not sure how we would judge "similar".
 
> 
> > 5) Create the actual ODF instance documents needed to meet the
requirements
> > of the Interoperability Test Requirements above.
> 
> -1. Rationale. Up to the test implementers. Test data really. You
won't know
> what is needed until you write the tests. Devious ..... could ensure
an
> implementation is good for these snippets (and no more). Test data
> needs to be very carefully considered when writing tests.
> 

There have been other test TC's at OASIS which have
delivered actual XML instance documents as a test suite.  We may as
well.  In fact, I think this is our primary contribution, and without
that we have not created anything of value.  The test specification
documents above are really just to document the traceability of the test
cases to the underlying ODF standard.

> 
> > 6) Write profile of ODF to improve interoperability in specific
areas.  I've
> > heard ODF for archiving and ODF for web mentioned.
> 
> -1 We haven't clearly defined profiles. How can we require them,
> how can Oasis test if we've got one back from the TC?
> Bit like interop. Leave it up to the TC to define profiles and
> produce an appropriate set of profiles of ODF, scoped to the latest
> Oasis standard.
> 

Profiles would be defined in #2 above, the Profiles
Requirements document. 

> 
> 
> > 7) Write guidelines for ODF implementors on various topics, i.e.,
how to use
> > the internationalization features of ODF.
> 
> -1. I think this workload would break the camels back. ODF implementation
> is orthogonal to compliance and interop testing. If anything, this
is a job
> for the main TC. Weak testability is due to their work. Let them fix
it.
> 
> This has nothing to do with compliance and interop. Hence my
> proposal to reduce the TC name.
> 

I understand your argument.  I'm on the fence
on this point.

> 
> > 8) Write a report on best practices in creating interoperable
documents with
> > ODF.
> 
> -1 as is. I want the TC to research interop, produce a definition
scoped
> to ODF apps and documents and then let the main TC know what they
have
> to do to improve it. Suggest this topic be changed into the feedback
to
> the main TC.
> 

Maybe you misunderstand.  This document would
be targeted to end users, those who author documents.  It would be
called something like "How to write interoperable documents using
ODF".  It would outline common non-interoperable features, and
the approved interoperable equivalents.  So, "Don't use spaces
to align text, use alignment".  That is a trivial example, but
there are more significant ones.  This is within scope of our work,
since our goal is to improve ODF interoperability, and the user is part
of the equation here.

> 
> > 9) Unspecified deliverables on improving interoperability with
other markup
> > languages, e.g., DITA, OOXML.
> 
> 
> -10. Out of scope. Make a clear scope statement that this TC shall
remain
> within the scope of the latest Oasis standard. Interop between ODF
apps
> and via ODF docs.
>

The idea is interop between ODF (the latest version,
if you insist) and other markup standards.  This would be things like
a profile of ODF + ISO PDF.

> 
> >
> > There may be some others (I need to go through the list traffic
again), but
> > does that list give you a better idea?
> 
> If I make time today I'll trawl the 350 emails to do that too.
> Pity the archives aren't retrievable as a text file (are they?)
> http://lists.oasis-open.org/archives/oiic-formation-discuss/
> 
> 
> 
> >
> >> If we can determine this "focus", the discussion
will be much more
> >> concise and directed (I believe).
> 
> 
> Would you do the same on scope please Rob. I take focus and
> scope to be the same thing?
> 

There is nothing formally called "focus"
in the charter.  I believe the underlying concern expressed here was
that of scope.  I find it easier to focus on the concrete -- the deliverables
-- and then write a scope clause that fits the deliverables. Otherwise
we're going to find that every change to the deliverables will require
a corresponding change to the scope, especially if we try to keep the scope
narrowly defined.

But I certainly will send out a proposed scope statement
once we agree on deliverables.

-Rob