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

[marbux <marbux@gmail.com>]

On Sat, Jun 21, 2008 at 4:00 AM, Peter Dolding <oiaohm@gmail.com> wrote:

xxx-snip-xxx

Peter, what  you have written is in effect an excellent use exposing
the need to identify the market requirements to be fulfilled by the
profile work. I encourage you not to back down from your quest to have
the market requirement you identify included among those identified in
the proposed TC's charter. Identification of market requirements to be
fulfilled by a standard is fundamental under the law governing
standards work.

You have every right to press for the market requirement you identify
to be identified in the charter for as a requirement to be fulfilled.
You need only refine it and submit it as a proposal to add that
requirement to the charter. If Rob Weir does not assert his OASIS
official leadership of this TC to arrive at consensus on your proposal
once submitted as a proposal for language to be included in the
charter, you may consult with your attorney about your rights to a
legal remedy.

In other words, don't be misled by Rob Weir's 800-pound gorilla act.
You have legal rights here. Rob and OASIS are the entities legally
charged with protecting your procedural rights and providing you with
due process.

I strongly recommend that you consider studying my CDRF proposal and
the discussion of the opportunity within the CDRF framework to
maintain parallel branches of profiles for the pixel perfect and
business process .profiles, with the pixel-perfect profiles as
supersets of the corresponding business process profiles. What you are
seeking could easily be plugged into that proposal as an elaboration
of the requirements in the pixel perfect branch of profiles. And that
would plug your requirements into the only interoperability framework
I am aware of that has been formally proposed as a charter
requirement.

You might draft your proposal as being both an amendment to my CDRF
proposal and a proposal in its own right independent of the CDRF
proposal. In other words, you could propose that your proposal be
added to the charter whether it is included as an elaboration of the
CDRF proposal or standing alone.

As to the specificity of the rendering's perfection, may I suggest
that what you are after could be achieved by a Charter requirement
that the TC establish conformance requirements for an app-neutral test
suite of renderings in the pixel perfect branch of profiles.

You may inspect such a test suite for three W3C profiles developed
using the CDRF framework at
<http://www.w3.org/2004/CDF/TestSuite/WICD_CDR_WP1/wicdmobile.xhtml>.
If you spend a little time with that test suite, you will notice the
following factors:

1. The test suite is not complete for all profiles.

1. All renderings providing the baseline for renderings are
app-neutral. They do not rubberstamp a particular implementation's
renderings. The renderings were developed before the implementations .

2. All baselline renderings are on a page that also includes links to
the relevant conformance requirements for that rendering as well as a
short written description of the app should display in order to
distinguish between correct and incorrect renderings. (That's a great
development resource for the folks working on implementaions.)

3. The test suite also tracks the stage of conformant implementation
of the test renderings by participating developers for each separate
rendering in the test suite. This allows intelligent conversations
between the developers about the need for refinements in the test
suite and conformance requirements. E.g., they can compare renderings
in each others' apps and spot trouble spots that tneed to be addressed
by improved conformance requirements and renderings. .

4. Add it all up whilst realizing that there is an agreed
interoperability framework at the foundation of that work (CDRF) and
you have interoperability between implementations of less and more
featureful profiles, plus conformance requirements and baseline
renderings for the folks who want guidance on rendering, and a system
for their collaborative development and implementation. .

I suggest that you consider proposing language for the Charter
requiring that profiles, conformance requirements essential to
achieving uniformity in rendering by implementations, a test suite,
and a conformance implementation tracking system all modeled on the
W3C CDRF/WICD profile approach be placed on the list of TC
deliverables.

What you want ain't rocket science. The methodology for achieving what
you want in standards work is well understood. The barrier to what you
want is not technical. It's the 800-pound gorillas that refuse to to
negotiate with anyone but each other. They merely make lame excuses
for excluding anyone but the vendors from the negotiation whose fruits
will be revealed only at the end of the TC formation process.

Sooner or later the antrust sharks and regulators will get around to
ODF or ODF will simply fade away because it does not fulfill
fundamental market requirements such as interoperability and
specification of a presentation layer.. Make your record of what you
want in the charter and you create grounds for the sharks and
regulators to nail the gorillas to the wall when the sharks and
regulators are ready to clean up the ODF mess. If the gorillas ignore
your proposal and make no effort to achieve consensus on the the
issues you raise in your proposal, all they do is to add to the
already considerable evidence of their antitrust violations in this
formation meeting.

In other words, in my opinion refining your desires into a proposal
for a charter requirement is worthwhile even if it is ignored by the
gorillas. It can and likely will backfire on them. The E.U.'s DG
Competition is watching what this set of 800-pound gorillas is doing
in their negotiations and is very concerned that a vendor-neutral
standard emerge. An office document standard that does not specify its
presentation layer ain't vendor neutral. Under-specification of a
standard and application dependencies in a standard are synonymous.
The result is vendor lock-in and illegal competitive advantage for the
folks with the biggest market share.

You are in my opinion right on the money both from a technical and
legal standpoint in identifying under-specification that *must* be
removed from the ODF standard.

Best regards,

Paul E. Merrell, J.D. (Marbux)

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