| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]
- From: firstname.lastname@example.org
- To: email@example.com
- Date: Mon, 16 Jun 2008 20:11:51 +0200
Paul, you make it sound like the use
of CDRF is the only logical choice here and that no one in their right
mind would fail to jump at the opportunity of using it to improve ODF interoperability.
Maybe you are right, maybe you are wrong. But what is the
objection to having the proposed TC investigate this possibility and make
their own decision on its suitability? If you are correct, what is
the problem with letting the TC confirm its suitability?
marbux <firstname.lastname@example.org> wrote on 06/16/2008
> On Mon, Jun 16, 2008 at 3:11 AM, Sander Marechal
> <email@example.com> wrote:
> > To explain myself a little bit better: I believe that this committee's
> > is focussed on interoperability in the ODF world, building test
> > tools that help ODF applications become compliant with the standard
> > helping ODF applications interoperate with each other. I don't
> > the committee's work includes the interoperability of ODF with
> > standards such as OOXML, CDF, UDF or even PDF and HTML for that
> You've have a very serious serious misconception. CDF is not a
> standard that ODF apps could interoperate with. CDF is the acronym
> the Compound Document Formats Working Group, a working group at W3C.
> That working group has one completed standard, the Compound Document
> by Reference Framework ("CDRF"). The working group is developing
> profiles for compound document formats using W3C markup languages,
> WICD profiles.
> But my proposals deal only with CDRF, the interop framework.
CDRF is *not* a format standard
> implemented by other applications that ODF implementations could
> interoperate with. It is a not a markup language or set of formats.
> is an *interoperability framework.* CDRF is an *application and
> format-neutral* specification that specifes:
> [i] requirements for development of compatible profiles of compound
> document formats working from a core profile to progressively
> super-setting profiles;
> [ii] requirements for creating compound document formats (unnecessary
> for ODF because ODF already *is* a set of compound document formats);
> [iii] a set of processing instructions and conformance requirements
> for round-trip interoperable processing of profiled content, including
> requirements for round-tripping between implementations of the less
> and more featureful profiles.
> The only barriers to achieving round-trip interop between
> implementations of less and more featureful ODF profiles using the
> CDRF specification are: [i] the work necessary to devevop the ODF
> profiles -- that everyone seems to agree are needed -- in conformance
> with the CDRF requirements for profile development; and [ii]
> minimal work necessary for developers to implement the processing
> instructions specified by CDRF for the processing of profiled content
> in conformance with the CDRF spec. Because CDRF was designed to be
> application and format-neutral, there are no application or format
> dependencies. CDRF is specifically designed to work with any
> combination of plain text-based formats.
> Why does this matter? I want to experience in my lifetime, e.g.,
> -- A triple pane outliner able to send an ODT to OpenOffice.org and
> have OpenOffice.org process that document in a manner that OOo can
> send the same document back to the outliner using only the markup
> vocabulary my outliner understands.
> --- A mobile device editor, Google Docs, KOffice, and OpenOffice.org
> able to process the same document in a business process with edits
> every way point along the processing chain and back again. I
> want just round-trip interoperability. I want multi-trip interop
> through a chain of different apps participating in a business process.
> CDRF not only enables this kind of round-trip processing between less
> and more featureful implementations; it requires it. Those are the
> kinds of interop doors opened by designating CDRF as the interop
> framework to be used for the ODF profile work. E.g., one provision
> from the CDRF conformance section reads: "A conformant
user agent of
> a superset profile specification must process subset profile content
> *as if it were* the superset profile content."
> I.e., an implementation of an ODF desktop word processor profile
> (more featureful) that opens a document generated by an implementation
> of a subset ODF web app editor profile (less featureful) would process
> the document as though the latter were the superset. The document
> then be edited in the more featureful app and sent back to the less
> featureful app in a vocabulary the less featureful app can understand
> and process correctly.
> User options to switch a document being processed to any supported
> super-setting profile or the full range of features supported by the
> app (non-profiled) would break the round-trip, but would allow a user
> to apply a richer vocabulary of markup to a document generated by
> implementation of less featureful profile. E.g., a user generates
> rough notes using his mobile device editor. then opens the document
> his desktop word processor and switches to the full feature set of
> word processor to massage the notes into a polished report.
> This is not a complete solution to the problem of round-tripping
> between less and more featureful implementations because: [i] apps
> that implement only a subset profile will still encounter documents
> that were written to a more featureful profile; and [ii] any
> implementation of a profile will encounter documents that are not
> written to any profile and that contain app-specific extensions to
> allowed by the ODF standard. .There is thus a need for a compatibility
> framework as well, markup and processing instructions for the
> processing of unrecognized metadata. I will save that discussion for
> another post.
> Does anyone else have a concrete work plan to allow less and more
> featureful apps to round trip ODF documents during our lifetimes?
> all ears to hear any better plan. But just saying the word "profiles"
> does not address what is necessary to achieve round-trip interop
> between less and more featureful apps. That takes an interop
> framework, and why should we develop our own when W3C has years into
> inventing that wheel for us? Just to create incompatibilities with
> W3C wheel? What other justification is there?
> Who here is willing to speak against round-trip interop between less
> and more featureful ODF apps? Both IBM and Sun did substantial work
> developing CDRF Both are helping build the WICD profiles W3C is
> developing using W3C formats. Both companies have the expertise and
> resources to implement this. Their representatives at this meeting
> need only consult with their fellow staffers to confirm that this
> feasible, assuming they have not already done so. We are in reality
> only discussing whether there will be a commitment to *achieving*
> interoperability including interop between less and more featureful
> There was an argument raised against my CDRF proposal that OASIS
> charters cannot specify the use of other standards in TC work. I offer
> in response, Requirements 2 and 4 of the OpenDocument Technical
> Committee Chater:
> "2. it must be *compatible* with the W3C Extensible Markup Language
> (XML) v1.0 and W3C Namespaces in XML v1.0 specifications,
> "4. it must be *friendly to* transformations using XSLT or similar
> XML-based languages or tools,"
> Will the opposition now argue that the ODF TC's charter violates OASIS
> requirements by requiring the use of other standards for compatiblity
> purposes? Are there any more excuses for not requiring round-trip
> interop between less and more featureful implementations of ODF? The
> programming techniques for achieving such interoperability are
> anything but new. What is new is an open standard that can be used
> with *any* plain text-based formats. Was the IBM opposition to
> competing standards and enthusiasm for harmonization and convergence
> in regard to ODF and OOXML only only a tactic to be discarded when
> came time to deal with ODF interoperability? Will this proposed TC
> reinvent the W3C interop wheel just to introduce incompatibilities?
> The choice is between a standard and a double standard. (Sorry,
> couldn't resist the quadruple entendre. :-)
> Best regards,
> Paul E. Merrell, J.D. (Marbux)
> Universal Interoperability Council
> To unsubscribe, e-mail: oiic-formation-discuss-
> For additional commands, e-mail: oiic-formation-discuss-
| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]