Re: [oiic-formation-discuss] MARBUX POINT OF ORDER, OBJECTION, AND SUGGESTIONS No. 1

[marbux <marbux@gmail.com>]

On Tue, Jun 17, 2008 at 1:11 AM, Sander Marechal
<sander.marechal@tribal.nl> wrote:

> * Referencing child objects is done by whatever way the parent format
> specifies natively.
> * An optional "profile" attribute can be used along side the content type
> * A way to access the child DOM from the parent DOM an vice-versa (including
> events)
> * Subset profiles can't ann features, only remove features from the base
> profile
>

I suspect that I've got way more time into studying that spec than you
do and my statements are also based on extensive tests we performed.

Still, I'm surprised that you missed the processing instructions in
the conformance section since I quoted one of them requiring interop
between implementations of less and more featureful implementations.
You missed more than that, but that should be enough to give you
reason to look a bit harder.

> Everything else you described in your (rather long) post is
> application-specific implementation of CDRF. Things that could be done. Not
> things that are defined in the spec.

Study the conformance section and the normative requirements. You
really have missed a lot. I'm not sure what you mean by "things that
could be done." It's ambiguous. Are you agreeing that they could be
done or merely referring back to my description?

> I have to agree with Rob Weir here. CDRF doesn't have a place in the
> charter. Have the TC figure out what the best way is to build profiles for
> ODF. Maybe that CDRF. Maybe it's something else. Maybe it's CDRF combined
> with something else (from reading the spec, it doesn't seem too hard to
> combine the CDRF recommendations in a more detailed profiling spec). It's
> very much dependent on what profiles need to be created and what the use for
> these profiles is.

To my knowledge, the word "interoperability" has not yet found its way
into either the requirements or the deliverables sections of the draft
Charter. Given the history of the interop mess the big vendors made of
ODF itself, I am unwilling to grant them the discretion to do the same
with the work of the proposed TC. E.g., creating profiles does not by
definition require that the processing instructions and conformance
requirements necessary to achieve interoperability be clearly and
unambiguously be specified.  Neither does it require that an
implementation of a supersetting profile process subset profile
content as though it were the superset.

I have no interest in handing this TC a check signed in blank to
continue blocking the round-trip interop of less featureful ODF
implementations with the more featureful implementations. Is that
discretion acceptable to you?

> Perhaps you should recommend CDRF to the TC once the TC has started and is
> working on profiles.

I am *not* going to join this TC unless the Charter *requires* interop
of the kind I have discussed. My experience of working on the ODF TC
is that the big vendors that control it are decidedly anti-interop.
They talk the interop talk but the interop walk they walk is
backwards. E.g., the draft ODF 1.2 creates even more interop
breakpoints than its predecessors. I wasted far too much of my time on
the ODF TC battling over those new interop breakpoints and lost. I'm
not going to do TC work on ODF interop again before there is a solid
and verifiable commitment by the big vendors to interop. Too many
scars on my noggin from butting against their stone walls.

Like I said, all Rob Weir and Michael Brauer have to do to confirm
that CDRF is adequate to the task is to talk to their company reps
serving on the W3C CDF Working Group, assuming they have not already
done so, which I doubt. .

What is missing from your post is the slightest indication that you
believe CDRF would not work for the purposes I specified. That fact
means that all your post offers this discussion is your personal
preference for letting the TC decide whether to actually deliver a
spec that enables round-trip interoperability between implementations
of less and more featureful profiles. .

Please either show us that CDRF won't work for the purposes I
described or make a counter-proposal that is even better for requiring
this TC to actually deliver interop of the kind I discuss. I have
heard no valid objections to my proposal thus far, just
trust-the-folks-who-haven't-delivered-interop-for-four-decades B.S.
Any version of the ODF spec proves that it's foolish to trust them to
deliver interop without a requirement that they do so.

I've got a proposal on the table that no one has come up with a
technical or legal objection to. To me, that looks like consensus that
there are no relevant and valid reasons for *not* specifying CDRF as
the interop framework for the profile work in the TC charter.

Got anything else to offer?

 Best regards,

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

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