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

[Sander Marechal <sander.marechal@tribal-im.com>]

marbux wrote:
> 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.

Not missed. Merely misunderstood. I re-read it and I think I understand
it better now. At least I see now how it could apply to your ideas. I'm
not 100% sure that that's exactly what the W3C wrote (because the
language pretty is vague to me) because this includes the unwritten
requirement that all applications support all profiles (or at least all
subprofiles of the superset they're implementing). This may be odd.

Hint: If you write shorter and more to-the-point posts I may have
understood the first time round.

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

I don't think CDRF will not work, but I think CDRF isn't the only way
that such interop could be achieved. It may not even be the best way. I
think that it's the TC's job to figure out if CDRF is the best way to
build profiles or something else. I don't think it's our job to figure
this out right now and put it in the charter.

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

Here's a counter proposal: Your main (sole?) reason for CDRF seems to be
the requirement that an application that conforms to some profile can
also handle it's sub profiles (read them, and write back to them,
allowing the less featureful app to open it again).

Why not take just this rule and put it in the charter as a requirement
for profiles, instead of using the entire CDRF?

Also an objection to your proposal: What if it turns out to be
impossible to create an interop profile without adding things to the
spec? Your requirement would mean that the TC failed and work stops - at
least until the next version of ODF rolls around that has the issue
fixed so that you can build the profile by just removing stuff.

Personally I'd prefer the TC to still come up with a profile for the
current ODF and continue working. Possibly with the added requirement to
recommend changes for the next version of ODF so that the next iteration
of profiles can be build correctly.