[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] Any interest in a "Design of ODF" Committee Note?
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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]