Re: [oiic-formation-discuss] (1)(d) A list of deliverables, with projectedcompletion dates.

[robert_weir@us.ibm.com]

marbux <marbux@gmail.com> wrote on 06/13/2008
03:36:07 PM:

> On Thu, Jun 12, 2008 at 11:06 AM,  <robert_weir@us.ibm.com>
wrote:
> >
> > Another piece I suggest we start working on:  "(1)(d)
A list of
> > deliverables, with projected completion dates".
> >
> > However, I'd suggest we discuss this as if it said "a list
of prioritized
> > list deliverables".  From a practical standpoint, it
is impossible to
> > project completion dates until we have a good idea who will be
joining the
> > proposed TC.  Those who do line up to join the TC can huddle
before we
> > submit the charter and turn the prioritization into projected
dates.
> >
> > So far I've heard the following items (in no particular order)
> >
> 1) A conformance test of ODF documents and implementations, i.e.,
test
> the formal shall's and should's, etc.
> 2) An Acid-style test of ODF implementations, i.e., feature and
> rendering-oriented, essentially highlighting ODF features that are
not
> widely implemented (or implemented correctly) but are desired (by
> whom???)
> 3) A comprehensive test suite of atomic (single feature) tests
> 4) A formal profile of ODF for portability and archiving, aka ODF/A
> 5) A formal profile of ODF for browser-based applications
> 6) A formal profile of ODF for mobile devices
> 7) A report on best practices for authoring portable documents
> 8) A periodic interoperability report on the state of ODF
> interoperability, with specific recommendations for implementors.
> >
> > What did I miss?
> 
> 1. The list omits my somewhat detailed proposal that this proposed
TC
> avoid reinventing the wheel and focus its profile development work
> within the context of the W3C Compound Document by Reference
> Framework's requirements for profile development.
> <http://lists.oasis-open.org/archives/oiic-formation-discuss/200806/
> msg00068.html>;
> see also follow-up post here.
> <http://lists.oasis-open.org/archives/oiic-formation-discuss/200806/
> msg00088.html>.
> 

This is an implementation detail, right?  Nothing
in the proposed list of deliverables restricts the form which profiles
can take.  The TC, when formed, will clearly want to investigate the
possibilities and chart a path forward.


> 3. The list omits my proposal in the same post that ODF profiles be
> developed that correspond to the feature sets of the W3C's Web
> Integration Compound Document profiles, with an eye on
> transformability between ODF and WICD profiles, round-trip
> interoperability between less and more featureful implementations
of
> ODF, and on the emerging convergence of desktop, server, Web, and
> mobile device editors and viewers. E.g., Microsoft Office achieves
> high fidelity interoperability with Sharepoint Server using OOXML
and
> from Sharepoint Server to several other Microsoft Web 2.0 applications
> using primarily XAML Why should ODF desktop implementations be unable
> to round-trip documents with web applications using ODF? The CDRF
> interoperability framework was specifically designed for such
> purposes.
> 

Same response as #1.  I'm not hearing a consensus
to dictate any specific technology for this.  So by default, we'll
defer to the new TC to investigate the possibilities.

> 2. The list omits your counter-proposal that this proposed TC set
 as
> its workplan "mov[ing] ODF interoperability forward one small
step
> [none identified] at a time"
> <http://lists.oasis-open.org/archives/oiic-formation-discuss/200806/
> msg00075.html>;
> see also your reply to my follow-up at
> <http://lists.oasis-open.org/archives/oiic-formation-discuss/200806/
> msg00092.html>.
> 

Question (1)(d) asks for a list of deliverables.  These
are not proposed deliverable.  They read to me like statements of
preferred working styles, answering the question "how" the TC
works, now "what" the TC produces.

> 3. The list omits several items in this proposed TC's formation
> scoping notice.
> <http://lists.oasis-open.org/archives/oiic-formation-discuss/200806/
> msg00001.html>:
> 

Well, that's the scope question, not the deliverables
question.  So that is question (1)(c)  not
(1)(d).

> a. "To publish test suites of ODF for applications of ODF to
check their
> conformance with the Standard and to confirm their
> interoperability[.]" The "confirmation of interoperability"
part seems
> to have not made it onto your list.
> 

test == confirm.  We got it covered, I think.

> b. "To provide feedback, where necessary, to the ODF TC on ways
in
> which the standard could improve interoperability[.]" This item
has
> been completely omitted.
> 

that will end up in the liaison question, (2)(a).
 It is not a statement of a deliverable, unless you want to propose
a formal feedback report.

> c. "To produce a set of implementation guidelines[.]" This
item is not
> unambiguously the same as the list's item 7, a "report on best
> practices for authoring portable documents."
> 

We're still discussing that point.


> d. "To define interoperability with related standards by the
creation of
> profiles or technical reports[.]" This item is totally missing.
> 

That may be in the scope, although we have not identified
a specific deliverable for it.  If pressed on the point, I'd add an
ODF/DITA profile to the list.

> e. "To coordinate, in conjunction with the ODF Adoption TC,  OASIS
InterOp
> demos related to ODF." This item is totally missing.
> 

Again, that is a scope question, not a deliverable
question.

> f. "The IIC TC may also liaise with other standard bodies whose
work
> is leveraged in present or future ODF specifications. These include,
> but are not limited to, the
> W3C and ISO/IEC JTC1/SC34." This item is completely missing.
> 

Again, this is not a deliverable.  It goes in
scope and any known specifics into(2)(a)

> 4. In regard to items 3 (a) and (b) above, please add an item to the
> effect that this TC will recommend to the OpenDocument TC a clear
and
> unambiguous specification of "conformity requirements essential
to
> achieve the interoperability," as required ISO/IEC/JTC 1 Directives,
> Annex I, in order to aid in bringing ODF into compliance with the
> Directives. <http://isotc.iso.org/livelink/livelink.exe/fetch/2000/
> 2489/186491/186605/AnnexI.html>.
> 

We cannot tell the unknown chair of the nonexistent
TC to tell the ODF TC to do something.  We should not pre-determine
the TC's conclusions.  Once we do that, then what's to prevent us
writing a charter that says IBM's implementations are be conformant by
definition?  We can't do that.  The charter is goal-oriented.
 We can't mandate the outcome of the TC's work.  This is OASIS,
not Ecma.

> 5. .  In regard to item 3(d) above and to all profiles produced
by the
> proposed TC, please add to the list (For purposes of this paragraph
> and its subparagraphs, "exit criterion" means a requirement
that must
> be complied with prior to a profile being submitted to the OASIS
> membership as a candidate OASIIS standard):
> 
> a. That each and every such profile be submitted to the OASIS
> membership as a candidate OASIS standard with this proposed TC
> nominated as the profile's maintainer;.
> 
> b. As an exit criterion, that each and every such profile before being
> submitted to the OASIS membership for adoption as an OASIS standard
> "clearly and unamiguously specifty the conformity requirements
> essential to achieve the interoperability within the meaning of the
> ISO/IEC/JTC 1 Directives, supra.
> 
> c. As an exit criterion, that each and every such profile fully comply
> with ISO/IEC/JTC 1 Directives, supra, and the Agreement on Technical
> Barriers to Trade, as applicable,
> <http://www.wto.org/english/res_e/booksp_e/analytic_index_e/tbt_01_e.htm>,
> and with all other applicable competition law such as Sherman Act
> section 1, 15 U.S.C. 1, and Article 81 of the Treaty on European Union
> and the Treaty Establishing the European Community as set forth in
the
> consolidated version.
> <http://europa.eu/eur-lex/pri/en/oj/dat/2002/c_325/c_32520021224en00010184.pdf
> >.

We can't rewrite OASIS rules in our charter.  The
approval requirements for OASIS Standards are already defined here:  http://www.oasis-open.org/committees/process.php#standApprovProcess

However, there is allowance for a TC to adopt standing
rules for the TC, so long as they do not contradict OASIS rules:

http://www.oasis-open.org/committees/process.php#procedure

So the proposed TC may be able to adopt such addition
restrictions as you describe.  But I don't see how we can impose such
working rules as part of the proposed charter.


>   However, I propose that rather than just fulfilling the requirements
> of the Agreemnt on Technical Barrier Trade's Best Practices section,
> <http://www.wto.org/english/res_e/booksp_e/analytic_index_e/tbt_02_e.htm#ann_3
> >,
> that the profiles meet the fulfill the more rigorous requirements
for
> international standards and technical regulations, so that the profile
> specifications are ready to become international standards and
> technical regulations.
> 

Same as above.

> d. As an exit criterion, that each and every such profile be fully
> implemented in at least two Different Information Technology Systems,
> at least one of which must be licensed under a free and open source
> software license recognized as compatible with the Gnu General Public
> License ("GPL") by the Free Software Foundation, as maintained
by that
> organization at
> <http://www.fsf.org/licensing/licenses/index_html#GPLCompatibleLicenses>
> or be licensed under the GPL itself. For purposes of this paragraph,
> tjhe phrase "Different Information Technology Systems" requires
that
> at least one implementation must not be a clone of the same code base,
> such as OpenOffice.org, StarOffice, and Lotus Symphony.
> 

Same as above.  A question to ask yourself is
"who would verify this?"  OASIS already has rules for what
is required for an OASIS standard, and OASIS staff ensures this is met
before we can have a ballot.  Would you expect them to verify whether
the implementations are GPL?  If so, the way do to that is by lobbying
the OASIS Board of Directors to change the OASIS rules.

> e. As an exit criterion, that each and every
such profile have fully
> developed and validated conformance and interoperability assessment
> procedures.
> 

Would we want to hold up publication of a profile
because the test suite for it was not yet available?  In some cases
this may be true.  But can we safely say that this is always true,
and that we would want to make that a charter requirement?  Or is
this something left to the good judgement of the TC?

Also, note that OASIS has new conformance clause requirements
which apply to all OASIS standards.  This rule was instituted since
ODF 1.1 and we'll be required to follow it in ODF 1.2.

> f. As an exit criterion, that the developers of each of the
> implementations described in paragraph 5(d) demonstrate that their
> implementations have achieved full fidelity round-trip
> interoperability with each other.
> 

OK.  I think you get the idea.  If the TC
wants to constrain itself in this way, then that is a working rule of the
TC.  It is not a TC deliverable.  In fact, it boogles the mind
why you took the time to put all this effort into an out of scope response
to a question that was clearly just asking for a list of documents the
TC will produce.  Oh well.

> g. As an exit criterion, that one implementation identified in
> paragraph 5(d) above that is licensed under a GPL or GPL-compatible
> license be designated by the proposed TC as the reference
> implementation for that profile.
> 

Ditto.

> h. As an exit criterion, that each and every such profile clearly
and
> unambiguously require that no extended version of a profile shall
be
> claimed as conformant with the same profile, as required by the
> Agreement on Technical Barriers to Trade..
> 

Ditto.

> i. As an exit criterion, that each and every such profile clearly
and
> unambiguously require that no implementation be deemed conformant
if
> it is incapable of round-tripping documents with conformant
> implementations without loss of fidelity.
> 

Ditto.

> j. As an exit criterion, that each and every such profile that
> supersets another such profile must clearly and unambiguously require
> that conformant status is denied to any implementation of a superset
> specification that does not process each and every subset profile's
> content as if it were the superset profile content.
> 

Ditto.

You know, Paul, if cleaned up, these points might
be a good match for what Michael was proposing, a "Profile Requirements"
document that would outline the TC's recommended approach to developing
profiles for ODF.  I have no idea if you would be interested in joining
the TC for such an effort, but even if not, this is something that could
be contributed to the TC.

> E.g., a conformant implementation of a more featureful desktop word
> processor profile that supersets a mobile device word processor
> profile must round be capable of round-tripping documents with a
> conformant implementation of the mobile device word processing profile
> with edits at each end of each trip, in the manner the W3C Compound
> Document by Reference Framework requires for interoperability: "A
> conformant user agent of a superset profile specification must process
> subset profile content as if it were the superset profile content."
> <http://www.w3.org/TR/CDR/#conformance>)
> 
> k. As an exit criterion, each and every such profile must specify
RFC
> 2119 as the defining standard for requirements key words.
> <http://www.ietf.org/rfc/rfc2119.txt>.
> 

That conflicts with your earlier point that "the
profiles meet the fulfill the more rigorous requirements for international
standards and technical regulations, so that the profile specifications
are ready to become international standards and technical regulations."
 

International standards use ISO Directives, Part 2,
Annex H for their control vocabulary, not RFC 2119.

> This is for compatibility with nearly every other XML standard in
> existence and to begin working out of the interoperability mess
> created in the ODF standard when ISO/IEC/JTC 1 switched ODF 1.0 from
> RFC 2119 to ISO/IEC Guidelines definitions, gutting EVERY mandatory
> interoperability requirement in the ODF standard by the switch from
> the modal RFC 2119 definition of "may" and "optional"
 --- which
> includes two "must" interoperability requirements --- to
a definition
> that gives "may" and "optional" their common and
ordinary meaning of
> "permission." This was a blunder of monumental proportions,
> particularly given that ISO/IEC Directives allow incorporation by
> reference of non-ISO/IEC standards and as nearly as I can tell from
> extensively studying the ODF TC email archives from that period, the
> JTC 1 Editor for ISO/IEC 26300 OpenDocument --- Patrick Durusau ---
> didn't bother even asking the ODF TC about the consequences of
> dropping EVERY mandatory interoperability requirement in the standard
> before he made that switch.)
> 
> 6. Please add to the list the development of a profile that matches
as
> closely as is feasible the requirements specified by IDABC and other
> European Union governments at the Open Document Exchange Formats
> Workshop 2007 and the Advancing eGovernment Conference.
> <http://ec.europa.eu/idabc/en/document/6474>.
> 

That is a bit vague.

> I may have more later.
> 

I look forward to it.


> Best regards,
> 
> Paul Merrell, J.D. (Marbux)
> 
> 
> 
> 
> -- 
> Universal Interoperability Council
> <http:www.universal-interop-council.org>