On Thursday, May 19, 2011 16:06:04 PM wrote:
> I've read some lamenting on the Doc Collab subcommittee list that we don't
> have an overall design or architecture document for ODF, something that
> explains the agreed on design constraints, approaches, etc. The standard
> itself describes the "what", but we don't have a doc that explains the
> "why".
>
> Of course, that doesn't mean that we don't have a design or architecture.
> It just means it was never written down, never codified. We have a lot of
> shared principles that have guided how ODF was put together.
>
> Although this lack of formality has worked in the past, it is not very
> optimal for those who are approaching ODF for the first time, especially
> for new TC members. Since I'd like to see the TC continue to grow and
> thrive and attract new members, this lack of a design document is
> non-optimal.
>
> So, I'm wondering if it would be worth putting together a Committee Note,
> something like "ODF: Design Principles", or "The Design of ODF", or
> (borrowing from Stroustrup) "The Design and Evolution of ODF"? As you
> may know, a Committee Note is a new kind of work product that OASIS
> enabled last year, for non-normative reports/whitepapers, etc. A
> Committee Note goes through the normal review and approval process, but do
> not have the effect of a standard.
>
> If there is some interest in this, I'd recommend that we start on the
> wiki, drafting an outline, and then having members volunteer for sections
> of interest. I think a document like this would be of moderate length,
> maybe 20-30 pages, in 6 or 7 sections.
>
> As a side effect, the effort put into producing this Committee Note would
> help us clarify for ourselves these principles, and this would make the
> work on ODF-Next a little easier.
I would like to help proofreading. Since I am only a TC member since a year, I
am not familiar with the way the format specification was thought out. I do
have quite a few points in the specification where I wonder about how the
design has come to pass and why certain limitations are present. As such an
explanatory note alongside the specification is very useful in helping
implementors and in finding places in the specification where improvements could
be made.
As to workflow, I am in favor of any system where one can link directly to the
different parts of the specification.
Best regards,
Jos
