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:
>
> Sander Marechal <sander.marechal@tribal.nl> wrote on 06/19/2008 01:43:57 PM:
>
>> robert_weir@us.ibm.com wrote:
>> > If there is consensus to make CDRF based profiles, then we would add
>> > that to the list of deliverables.  If there was consensus to require
>> > only CDRF based profiles, then we would add that restriction to the
>> > scope statement.  But I'm not hearing consensus on either of those.
>>
>> The rotten part IMHO is that the CDRF spec actually deals with two
>> issues: compound documents and profiles. I don't think the compound
>> documents stuff is particularly interesting for ODF or how that part
>> would impact ODF, but the bits about the profiles is certainly
>> interesting.

I'd add a couple other parts of CDRF to your short list and have a
suggestion that might resolve concerns about the compound documents
parts of CDRF.

You have on your list of CDRF key features and I will fl it out just a
bit more.:

1. A specification for creating conformant compound document formats;

2. A specification for creating compatible profiles working from a
core profile to progressively more featureful profiles.

3. A specification for the interoperable processing of profiled
content including round tripping between implementations of less and
more featureful profiles.

4. A very key conformance requirement that leaves no discretion for an
implementation of a supersetting profile not to be capable of
processing each subset profile's content as if the subset profile were
the superset profile.

Together with the more detailed requirements, we have in sum an
interoperability framework that requires not only that implementations
of particular profiles be interoperable, but that more featureful
implementations must interoperate with implementations of less
featureful profiles. As an analogy, one need not replicate the entire
range of functionality of OpenOffice. org in order to achieve
round-trip interoperability with it. The mobile device editor can
round trip documents with OOo with no loss of data.

The folks who implement only less featureful profiles can have
confidence that their ability to round trip documents with more
featureful implementations will not be left behind as more featureful
profiles are developed and implemented. One need no longer clone the
OOo code base to round-trip documents with OOo without checking
documents manually for loss of data.

What I really seek here is to pitch the software stack model overboard
and replace it with an ecosystem of interoperable apps of varying
capabilities. The mega-apps like OOo and Symphony become even more
valuable because they in effect become the major document interchange
centers in the ecosystem, the place a user can go to process any
profiled content.

Another huge advantage of this approach is that developers of less
featureful apps will have far more incentive to collaborate on
development of profiles for the range of features required by their
class of app. E.g., an outliner document exchange profile, a web
editor document exchange profile, a mobile device editor document
exchange profile, etc. If we go in that direction, we set in motion
the rising tide that raises all boats equally. And with each new
profile, the more featureful apps become more useful to their users.
Where developers of less featureful apps have requirements that can
not be expressed in any profile, they have huge incentives to get
their needed markup added to the next version of a profile and its
supersetting profiles. .

Everyone involved gets the stability of competing in a market that
will not leave them behind. So long as we dp not bestow conformant
status on documents that include app-specific extensions, we have
DOCUMENT EXHANGE FORMATS. Developers can still innovate and embrace
and extend profiles, i.e., innovation is still enabled, but users have
the option to write to defined profiles for purposes of document
exchange. Sometimes users will wish to write to embraced and extended
profiles. Sometimes they will not. But they have the means to round
trip documents with any conformant implementation of any profile.

In the final analysis, my reasons for wanting this approach has
nothing to do with the law. I want a document standard designed for a
connected world rather than for an application type from the sneaker
net days. I want my outliner to be able not just to talk to my word
processor, but for my word processor also to be able to talk to my
outliner. I want a two way conversation with the folks who are  using
those new-fangled mobile devices (that I will never touch myself :-).
I want a two-way conversation with a web app editor. I want two-way
conversations with every app in the world.

I speak as a software user. I want interop just as broad and universal
as I can get.  I am not against new features. I love new features. But
I am frustrated beyond comprhension by the fact that I can't exchange
documents in a non lossy way with anyone not using the same
application. It is *at least* ten times as frustrating to me because I
know beyond any reasonable doubt that there is no technical barrier to
to the kind of interop I want for documents.

The only barrier is the big vendors' fear of not being able to control
their markets. But that fear is completely irrational. Deliver the
kind of interop I want based on open standards, and the world will
beat its feet to your doors. There will be an explosion of
opportunities to commercialize interoperability in a connected world.
I speak of economic expansion instead of market control that stunts
economic expansion. I speak not only of the explosive kind of
commerical growth that HTML brought to the world but the even more
explosive growth brought by more and less featureful apps being able
to hold 2-way conversations.

I fully comprehend that my wildest interop desires are infeasible. But
I'm still waiting for that first tiny step of producing
implementations of a standard for the interoperable exchange of
documents by any office productivity software. Four decades, Rob,
since IBM embraced and extended the Teletypesetter ("TTS") telegraphy
code to begin the commercialization of automated word processing. The
last interoperable word processor I used punched paper tape to
unextended TTS and it was electro-mechanical rather than electronic.

As to the portions of CDRF that provide rules for creation of compound
document formats, an interoperable ODF can be treated as  single
formats for each application type. The only relevance of the rules for
creation of compoound document formats would be for those who wish to
combine ODF with other formats. In my view, that does not mean that
the problem with the incorrect implementation of three W3C standards
in ODF using unique OASIS namespaces need never be addressed. There
are severe round-trip transformation problems there that I suspect can
only be resolved by going to W3C for development of profiles for the
feature range needed in ODF and to get the ODF 3-D stuff into a W3C
standard that harmonizes SVG with it.

But I see no need to treat ODF at least initially as anything but a
single format for each application type. I suspect that the  CDRF
rules for creating compound document formats may be a helpful guide in
addressing the incorrect namespace issue at some later date. But in
terms of getting started on the profile work, I see no immediate need
for ODF to conform to those rules. E.g., treat ODT as a single format
and do the ODF profile work. The rules for creating compound document
formats need only relate to the combining of ODF with other formats.

>>
>> Perhaps there is a way to just use the profiles aspect of CDRF and leave
>> out the rest? Would it be easier to achieve consensus on just that part?

With the caveat just given, I hope you might instead move closer to
compatibiility with the whole of CDRF as the guide. I am certainly
willing to consider language that would allow flexibility where it is
necessary. E.g., there's a definition of  "user agent" incorporated by
reference in CDRF that read literally excludes editing implementations
from the conformance requirement for round trip interop between
implementations of less and more featureful profiles. I certainly
could not say that no other adaptations would be required along the
way. But I think we might fix that with language requiring the maximum
compatibility with CDRF that is feasible. I'm not ready to agree to
the specific words I just used to impart the idea, but I'm open to
some language that provides needed flexibility but limits the
flexibity to that needed. I'm not here to be unreasonable. W3C itself
added the "conforming authoring tool" definition to the WICD profiles
rather than fixing the problematic definition incorporated by
reference in CDRF.

CDRF is far more valuable in my mind for its interop conformance
requirements including the application behavior specified than it is
for its profile development specs. I'd hazard an informed guess that
the CDRF interop conformance requirements could be used with other
profile development specs. But then we're getting into trying to
cobble pieces of other open standards together to create a complete
interop framework. I wouldn't want to just gamble that there are other
suitable cookbooks out there for creating profiles that are compatible
with each other in a manner that enables round-tripping. documents
between implementations of less and more featureful profiles.

I'm also not wedded to CDRF if someone comes up with a better
proposal. But I'm totally against writing a blank check for the
proposed TC. I want a mandate for the TC to deliver specs for
interoperable implementations of profiles and for interop between
implementations of less and more featureful profiles. In other words,
I want an identified interop framework in the charter and if anyone
knows of a better framework for the purpose, I want time to evaluate
it before we specify it instead. Another way of saying what I want is
a concrete and detailed work plan to achieve the goal of the best
interop achievable. Specifying in the charter harmonization of ODF in
the profile work with a specifically-identified existing open standard
interop framework should be the goal here, I think.

CDRF would also open the door to an eventual profile for
transformations to and from the ePub standard just adopted by the
global eBook publisher's association.  <http://www.openebook.org/>
ePub is built on CDRF and if ODF vendors want to participate in that
market using their ODF apps, they are going to need to implement CDRF
and develop a profile for non-lossy transformations between ODF and
EPub. I guess the point here is that CDRF is gaining major traction
for non-W3C formats already, W3C has the recognized lead in XML
formats, harmonization with an existing standard is no small
consideration, and I am not content with leaving the selection of the
interop framework up to the TC.  Like I said before, I'm still looking
for that unmistakable signal that the big ODF vendors have turned a
square corner on their ODF interop policies. The signal I want is
commitment to CDRF or better in the charter.

With CDRF, I think down the line we might think about ODF profiles
that correspond to the feature sets of the WICD profiles if
implementation of the WICD profiles should gain traction. That would
add easy transformations to and from the WICD profiles to the ODF
connectivity arsenal. But I also think it's too early to say with
confidence that the WICD profiles are going to gain that traction.
There's not much in the works in terms of editors that I know of.

I think the biggest uptake barrier for the WICD profiles as document
exchange formats is that there aren't very many people visibly working
on editors for them. Because ODF has lots of editing implementations
and huge market share compared to the WICD profiles, I see ODF
document exchange profiles based on CDRF with huge potential to become
the universal document exchange formats.

I'll also point out that specifying CDRF in the charter limits not
only Sun and IBM's discretion but also Microsoft's. When Microsoft
announced plans for native ODF support in Office, its officials
reportedly said that they would provide that support but wouldn't
limit the Office features available to the user when creating
documents. All the users are supposed to get is a warning that writing
to ODF may result in data loss. CDRF  removes discretion for that kind
of game through its requirement that implementations of a supersetting
profle must process any subset profile as it it were the superset
profile. I.e., to claim conformance with the ODF profiles using CDRF
conformance requirements, Microsoft would be forced in order to claim
conformance round trip documents with every subset profile. The
compatibility mode and blocking out of features available to the user
when conversing with an implementation of a subset profile becomes
mandatory.

So CDRF also offers a way to force Microsoft to play nice with less
featureful apps if it wants to claim conformance with the ODF
profiles. CDRF also provides a roadmap for DG Competition to force
Microsoft to play nice with the less featureful ODF apps by requiring
Microsoft's conformance with CDRF-based ODF profiles. I've seen no
sign so far that IBM and Sun have given DG Competition any such
roadmap to enforce that would result in non-lossy interop between
Office and ODF apps. And the Microsoft officials' statements testify
that Microsoft has no goal of achiving non-lossy interop with any ODF
app.

I talk here of opening up the office productivity software software
market to open standards-based universal interop including the interop
of less and more featureful apps. I want everyone who implements a
profile to play nice with everyone else who implements any of the
profiles. I want an end to interop barriers in the office productivity
software market and I want the traditional office desktop suite
developers to do 2-way conversations with less featureful apps,
whether those apps be located on the desktop, the server, mobile
devices, or the Web. And I want it to be based on open standards.

Four decades is four decades too long to wait for the software
industry to treat their users like valued customers rather than
victims to be locked in. I want an end to this crap and that's why I
want CDRF. I wanted interop 40 years ago and the frustration has just
kept building roughly linearly as the number of incompatible apps has
mushroomed. As Sam Hiser told Bob Sutor, "give me interop or give me
death."

With me, making interop happen is a non-negotiable item. The problem
just gets harder to solve with every non-interoperable app. CDRF is
the only coherent roadmap for solving those problems that I have found
and I have looked far and wide. So for me it's CDRF or better in the
Charter. I want the TC's hands to be tied to making interop happen. No
more excuses. I've heard them all. CDRF or better in the charter. No
consensus will be achieved without it. For folks who don't know
standards law, consensus means lack of sustained opposition. I doubt
that anyone here will dispute that I am capable of sustained
opposition.

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

Not good enough for me. You ask that I trust the big vendors who
created the interop mess. I do not and I have solid grounds for not
trusting them. .

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

I quote from the scope section fo the ODF TC charter:

"A standard for office document processing and *interchange* will be
of great utility to many users and software companies developing
applications, and should be made available as soon as possible."

.As part of the Phase 1 work in developing OASIS ODF v. 1.0, the ODF
TC Charter identifies the following work item:

"establishing a set of 'core' elements and attributes to be supported
by all implementations,"

However, even in OASIS ODF 1.1, we find the following passage in the
conformance section:

"There are *no rules regarding the elements and attributes that
actually have to be supported* by conforming applications, except that
applications *should not* use foreign elements and attributes for
features defined in the OpenDocument schema. "

"Should not" creates no conformance requirement; it is only a
recommendation. All elements and attributes in an ODF file can be
written in OOXML and it is still a conformant ODF document.

To summarize, the ODF TC Charter itself contemplated that OASIS ODF
1.0 itself would be profiled. And Six years later, we are still
waiting for those "interchange" formats that "should be made available
as soon as possible." Instead of interchange formats, we have total
developer freedom to claim conformance for a document where all
elements and attributes can be written in any markup language in the
world, even in proprietary binary formats. The profile work
contemplated for this TC invades the Charter of the ODF TC.

There will be no consensus achieved on trusting  the big vendors who
ignored the very purpose of the ODF TC, an open standard for document
interchange formats. No more discretion for abuse of software users.
CDRF or better in the charter. I will agree to nothing less.

Best regards,

Paul

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