Re: [office] Any interest in a "Design of ODF" Committee Note?

[robert_weir@us.ibm.com]

Patrick Durusau <patrick@durusau.net> wrote on 05/19/2011 10:33:12 AM:

> 
> Rob,
> 
> +1!
> 
> Question though:
> 
> Are we documenting the design/architecture that got us to this point or 
> is this a document to establish the design/architecture going forward?
> 

What is our audience? 

If it is primarily external, the consumers of the ODF 1.2 standard, then 
that is one thing.  But I think a document for them would be more along 
the lines of an implementors guide.  Something that explains how to use 
the features of ODF, how to do accessibility, how to do Bidi, etc.  An 
implementors guide would natural touch on "why" questions, to the extent 
that helps implementors understand the "how". 

An internal audience of TC members is another possibility and that would 
be more a document of the design principles.  Such a document could 
conceivably be of interest to ISO reviewers as well.  I think I'd start 
with existing principles, but I'd have no objections to adding 
forward-looking principles as well.  We might also find areas of ODF that 
do not adhere to the principles that we all agree on.  That is always 
possible.  But the purpose of the document would be to guide the evolution 
of ODF going forward.

> The reason I ask is that I have seen some comments and may have made 
> some comments about making ODF more "modular," which could imply a 
> different set of principles that those we have followed to this point.
>
> I am deliberately being vague about "modular" because it is premature to 

> start discussing details when we are trying to decide on drafting a 
> design/architecture document.
>

I could certainly see a statement about modularity at the schema level, to 
the extent we can express a compatible schema in a more modular way.  But 
modularization at the application level, I think it is hard to express a 
principle around that until we have some implementation experience around 
it.

So I think we can be forward-thinking in the principles, but we want the 
principles to be based on solid experience, ideally implementation 
experience.  In fact, one of our principles might very well be about the 
importance of implementation experience in driving the evolution of ODF 
features.

 
> I think your idea is a very good one, even though it will take quite 
> some effort and discussion to put into place.
> 

I'm hoping that putting together such a doc will have benefits as an end 
product, but also that the activity if discussing and agreeing on the 
contents will itself have benefits for the TC.

-Rob


> Hope you are having a great day!
> 
> Patrick
> 
> On 5/19/2011 10:06 AM, robert_weir@us.ibm.com 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.
> >
> >
> > -Rob
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail.  Follow this link to all your TCs in OASIS at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> 
> -- 
> Patrick Durusau
> patrick@durusau.net
> Chair, V1 - US TAG to JTC 1/SC 34
> Convener, JTC 1/SC 34/WG 3 (Topic Maps)
> Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
> Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)
> 
> Another Word For It (blog): http://tm.durusau.net
> Homepage: http://www.durusau.net
> Twitter: patrickDurusau
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>