Re: [oiic-formation-discuss] The importance to users of documents looking the same

[marbux <marbux@gmail.com>]

On Thu, Jun 19, 2008 at 8:50 AM,  <robert_weir@us.ibm.com> wrote:
>
> The proposed TC can certainly reuse parts of existing open standards.  ODF
> itself does this in many places with MathML, XForms, etc.  I think the
> proposed TC should, as one of its initial tasks, take a broad look at
> profiles and profile conventions from OASIS, W3C, ISO/IEC, etc., and create
> an "ODF Profile Requirements" documents that state the TC's agreed-upon way
> of writing profiles.
>
> In terms of the charter, I'd suggest adding the "ODF Profile Requirements"
> report to the list of deliverables.  But I think it is premature, not having
> done completed the research, to put specific technical limitations regarding
> profiles into the charter.

Rob, I think everything this meeting does could be dramatically
simplifed if we can achieve consensus that the interoperable
implementation of the profiles to be developed is the goal.

My principle reasons for suggesting the achievement of consensus on
that goal are that: [i] it is impossible to achieve profiles that may
be implemented in an interoperable way without breaking compatibility
with the ODF standard because of the mountain of application
dependencies in the ODF standard including the near total developer
discretion discretion bestowed by its conformance section; [ii] if the
goal is profiles that are both compatible with the ODF standard and
enable interoperability among different IT systems, the proposed TC
would have only an advisory role in its profile and conformity
assessment procedures that would have to be adopted by the ODF TC and
incorporated into the ODF standard; and [iii] the proper place for an
advisory committee to the ODF TC is a subcommittee of that TC, not a
new TC.

We need a decision on whether the goal is" [i[ to create profiles that
break compatibility with ODF by enabling interoperable
implementations of the profiles, creating conformity requirements
necessary to achieve that interoperability; and creating conformity
assessment procedures for those conformity requirements; or  [ii] to
do such work in a way that maintains compatibility with the ODF
standard, which would require substantial changes in the ODF
standard.and its implementations.

If the goal is the latter, the proper place for an advisory committee
to the ODF TC is a subcommittee of the ODF TC. If the former, then I
see a legitimate role for a new TC if developers commit to
implementing the profiles. But I see no need for a new TC if its role
is only advisory. OASIS policy says that the place for advisory
committees is subcommittees of the TC to be advised.

So I see consensus on the goal of interoperable implementations of the
profiles as the first step in a process designed to bring some order
to this chaos. Assuming consensus on that goal, the choice between
maintaining compatibility with the ODF standard or breaking
compatibility with it would in effect determine whether the work
should be done on a new TC or on a subcommittee of the ODF TC, or at
least force a discussion of how the work of the two TCs could be
integrated.

If you are willing to follow this suggested approach, I could very
quickly bang out some language derived from the JTC 1 Directives and
the Court of First Instance decision in Commission v. Microsoft as a
proposed item of consensus on the first step I suggest. The two
sources are in complete harmony but the antitrust decision fleshes out
some detail that it takes a lawyer or a grammarian to derive from the
JTC 1 Directives requirement. I've already got that done in the
Universally Accessible and Interoperable Specification. It's almost
entirely a cut and paste job for me to bang out that proposal.along
with its legal justification. It's something I could have done in a
half-hour.

Basically what I propose is the definition of interoperability in JTC
1 Directives and the Directives mandate to specfiy conformity
requirements essential to achieve the interoperability and to minimize
the number of options. All else is just to make the language
understandable to more people. The proposal would take the form of a
requirement applying to the specs for all deliverables within the
ambit of the proposal. I think this approach could lead us to some
important decisions that are currently blocking consensus, starting
with the need for a separate TC.

We need some leadership here. What say you?

Best personal regards,

Paul

-- 
Universal Interoperability Council
<http:www.universal-interop-council.org>