Re: [oiic-formation-discuss] Profiles: suggested use-cases

["Peter Dolding" <oiaohm@gmail.com>]

On Mon, Jun 30, 2008 at 10:08 AM, marbux <marbux@gmail.com> wrote:
> On Sun, Jun 22, 2008 at 2:24 PM, Sander Marechal <s.marechal@jejik.com> wrote:
>> marbux wrote:
>> Have you read my use-cases? Read the second one again, then read CDRF
>> again. There's nothing like it in the CDRF spec. As Simon and other
>> people have already pointed out to you, there's nothing in CDRF that
>> tells a subset application how to deal with a document from the
>> superset. It only tells superset applications how to deal with the
>> subset (and that's in my first use-case).
>
> Sorry for the delay in getting back to this thread. I agree that CDRF
> does not deal with your second use case and that is a weakness that
> needs to be addressed. I've already proposed in another thread, that
> CDRF be supplemented with a compatibility framework for the less
> featureful apps to process markup they don't support.
>
> There is a basic compatibility framework for this already in the ODF
> spec, in the conformance section. But it won't make a lot of sense to
> you unless you realize that ODF was developed using the RFC 2119 modal
> definition of "may" that imposes two mandatory interoperability
> requirements that directly read on the interop between less and more
> featureful apps. The RFC 2119 definitions got toggled off at JTC 1
> without any effort to repair the damage to the spec.
>
> It isn't the only way a compatibility framework could be created, but
> it's the way that is most compatible with the existing standard. I
> haven't thought through how that particular framework might mesh with
> CDRF. But off the top of my head it seems like it might work if the
> compatibility framework was part of the core profile.
>
Have no one leart the lessons of history here.

Round tripping between ODF and other programs causing data loss that
is grounds to expand ODF with new features and new formal ways of
processing that data to improve every ODF application out there.  Not
adding black boxes that say hey app you have some feature that is not
compatible you can put it in here and render better than every other
ODF application out there.  That is not interoperability that is
allowing vendor lock in.   That is where the foreigner data is nuke.
Asking a TC to support black boxes is asking to be kicked in teeth.

There are really no room for that many subsets.   If a ODF application
can render to full scale ie has a high enough resultion if you build
in support for a compacted PDA spec the full application must and I do
mean must be able to render the PDA form.   This is interoperability
user producing a document must not need to send it to a PDA to see if
it works or not just flick a switch ok that is perfect.   Also the
reverse has to remain true PDA must be able to handle ODF without its
extra hints.  Ie be able to create them if they are missing.

Step up to interoperability and compatibility stop trying to create
loop holes so you don't have to face them.   End result of loop holes
is the html mess the rdf mess  the tiff mess and the list goes on most
of the formats failed to deliver promised interoperability and
compatibility because the loop holes ended up allowing vendor lock in
to completely fragmenting the format.   Please hope no one is that
stupid as to be trying to do that.

Peter Dolding