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

[jose lorenzo <hozelda@yahoo.com>]

--- On Wed, 6/18/08, marbux <marbux@gmail.com> wrote:

> From: marbux <marbux@gmail.com>
> Subject: Re: [oiic-formation-discuss] MARBUX POINT OF ORDER, OBJECTION, AND SUGGESTIONS No. 1
> To: "Sander Marechal" <sander.marechal@tribal-im.com>
> Cc: oiic-formation-discuss@lists.oasis-open.org
> Date: Wednesday, June 18, 2008, 2:17 PM
> On Tue, Jun 17, 2008 at 6:40 AM, Sander Marechal
> <sander.marechal@tribal-im.com> wrote:
> > 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?
> 
> A few example reasons:
> 
> 1. Avoidance of duplicative but incompatible standards for
> the same
> functionality, as with the objections to OOXML because ODF
> was already
> the standard. There is a global effort under way to
> harmonize and
> converge standards to reduce unnecessary obstacles to
> international
> trade. I support that goal.

It seems trivial and noncontroversial to participate in CDRF as far as allowing ODF to be embedded in CDRF multidocuments (exposing it's DOM and events, etc).

What is interesting would be to build a family of CDRF profiles a la WICD that describe how ODF mixed with other XML standards; however, I suggest that at this point in time this be put on the plate for the TC as a low priority item (it may get done but more research is required). We should study this issue before creating profiles.

We should also note that ODF is already an amalgram of subsets of various W3C+other standards+native newly defined ODF document based components.

A higher prio at this point might be for the TC to design ODF profiles and profile interop rules of engagement within itself.

It seems natural at some point to consider what glue code (elements, attribs, semantics) would be needed to have ODF intermixed with SVG and others to build CDRF profiles, but that may be too large a task to be considered a deliverable for this TC. [I agree with Rob that this may not be the most worthwhile approach as it depends on what we want to do with ODF and also whether this TC will handle that.] I suggest people look over the CDRF spec (it's light if you have experience looking at other W3C standards); however, the conformance requirements (gathered in an appendix) are something that can easily be included to some degree within ODF and even used in part to define intra-ODF profile interop.

As for intraODF profiles, I think its natural to consider nonoverlapping profile sets. Perhaps make it somewhat modules based.

I also think that we should have the TC define how it will engage ODF users to define (standardize) these profiles for the various industries and for various use cases and how to continue that work into the future.

> 
> 2. We can actually achieve high quality interop far sooner
> if we use
> an existing cookbook for the TC's work rather than
> starting from
> scratch.

Their "cookbook" is not an issue. WICD, the only profile I saw, is a natural profile because XHTML, CSS, and svg-ish standards were already intended to work together. WICD simply standardizes that approach for the host application. There isn't too much of a cookbook that would be so difficult to graft into intraODF profiles, especially since building a CDRF or ODF profile would be starting from scratch and we'd study WICD anyway. CDRF, the container and what we would want to be compat with initially, is light.

This said, I too think CDRF and potential integration with W3C standards could be very desirable and should be studied. ODF can certainly contribute document-based markup.

Remember we have ODF profiles, a thorough testing framework, and the rules of engagement to be built. Keep in mind too that the W3C has been around for a long time. There is probably (?) no rush to get this integration (if desirable) done within a very short time. ODF is a document standard today, and people want to use the particular mix ODF presents.

Personally, I am looking at ways to make ODF stay useful without being extended out of existence, especially, by any particularly strong market player. For me this is a very high priority item, in part, for the sake of OO.o and other FOSS products.

> 
> 3. W3C has the lead on  XML and related markup languages.
> CDRF was
> designed for the purpose. There are enormous opportunities
> if we
> maintain compatibility with CDRF; e.g., dramatically
> improved
> transformability, a cookbook for combining ODF with other
> formats,
> avoiding future incompatibilities like the three W3C
> formats
> implemented incorrrectly in ODF with unique OASIS
> namespaces rather
> than the correct W3C namespaces, on and on.

OK, I see what you mean by cookbook. Once we build the intraODF profiles, we'd have (somewhat) of a recipe for engaging other W3C protocols if we maintained compat with CDRF. We should keep eyes open, without being detrimental to ODF and FOSS (my pov). [Also, I still haven't had a chance to see what makes ODF so vendor specific.]

BTW, OASIS namespaces are for various items deemed to be missing at some point in the past from the wider XML world. Any real criticism of this namespace, suggesting something else, should come with examples of exactly what else and why a replacement of those ODF elements would be preferable to fixing the ODF elements.

I appreciate this direction towards the W3C as a way to make life easier for other vendors. I also suspect there is politics/economics involved here (who gets paid what by whom).

A primary concern I have is that the market be opened up and that FOSS implementations have a real shot. Openoffice already works with ODF. What is the opinion of KOffice and others over ODF? Is it really that difficult to implement it?

I also think we really could benefit from a very accurate reference implementation that does everything correctly. By far, a streamlined OO.o seems like the top contender for this spot at this point in time. The TC needs to adopt such a ref impl and decide how to get it to be conformant at the highest levels.

[Note, I have not read through the whole standard, so I really appreciate examples of the ODF elements allegedly linked to OO.o and not sound otherwise.]

> 
> 4. Right now, ODF is designed only to serve the needs of
> traditional
> client-side desktop applications and the work to remove OOo
> dependencies in it is far from complete. CDRF is designed
> to converge
> support for apps on the desktop, servers, mobile devices,
> and the Web.
> If ODF does not participate in that convergence, ODF will
> become
> obsolete far sooner.

Again, I have not read the spec. I look forward to specifics from you or others. 

One thing I really believe in, especially while interest is high, is for us during the 90 day period to build examples, prototypes, proofs of concepts, etc of what the TC might do. This will help the TC's work and help build a charter that is better thought out and more solid. In fact, now we have the maximum chance for public participation.

This approach would be analogous to building small half-made buildings in order to test out theories and designs in order to develop a good and realistic design plan that will then be used to build the ultimate building in the next round.

So I do hope to start seeing something that actually might look like an ODF profile one way or another. The sooner this happens, the more it can be criticized ahead of time, allowing TC members to go in with more confidence and a better plan.

> 
> 4. W3C is far more strict about vendor neutrality in its
> work than
> OASIS. CDRF constrains the folks inclined toward
> manipulating this
> TC's work for unfair competitive advantage and
> eliminates a host of
> future arguments. It's the difference between having an
> agreed recipe
> and trying to do committee work to create a new recipe that
> could only
> introduce incompatibilities with CDRF were the new recipe
> any
> different from CDRF. Compatibility with CDRF should be the
> guide.

CDRF specifies very little. It should not be too much of a problem staying at or close to compat (I say this still having much to read in ODF). We should look at the CDRF conformance reqs gathered in their appendix. CDRF itself imposes little of immediate on other XML standards (it's geared more towards the applications). Building suitable profiles is another matter, but it should not be too difficult to retain compat (or add it in later) with CDRF itself. To interop with WICD and other profiles to come, we would need to consider many things.

....

I'll read the rest of your post later.