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


Help: OASIS Mailing Lists Help | MarkMail Help

oiic-formation-discuss message

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

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

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.
> <
> msg00068.html>;
> see also follow-up post here.
> <
> 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"
> <
> msg00075.html>;
> see also your reply to my follow-up at
> <
> 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.
> <
> 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. <
> 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,
> <
> 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.
> <
> >.

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:


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,
> <
> >,
> 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
> <
> 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.


> 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..


> 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.


> 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.


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."
> <
> k. As an exit criterion, each and every such profile must specify RFC
> 2119 as the defining standard for requirements key words.
> <

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.
> <

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
> <

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