[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-comment] 8.5.4 of ODF 1.0
--- On Mon, 7/7/08, MURATA Makoto (FAMILY Given) <email@example.com> wrote: > From: MURATA Makoto (FAMILY Given) <firstname.lastname@example.org> > Subject: Re: [office-comment] 8.5.4 of ODF 1.0 > To: "ODF Comments List" <email@example.com> > Date: Monday, July 7, 2008, 10:20 AM > Patrick, > > This is not a black-and-white issue. The editors > have to rely on their taste, experiences, and so forth. ... > As an editor, I tend to write dense specifications. > However, when I > read specifications, I do like comprehensive specifications > with ample > examples. I certainly think that OOXML is more readable > than ODF and > that translation of OOXML will be easier than that of ODF. But OOXML left itself more at risk to inconsistencies because of that. The more the standard says, the more the chance of an inconsistency, especially when the added test is informal in tone and language. If you follow the example, you can miss out on something great. You may fear deviating from the example because you'd otherwise run up against some inconsistency. Meanwhile, someone else goes with the more formal text's best interpretation and goes against the example. Which is the better decision to have taken? Well, it's the decision that puts you on the side that ends up taking the most marketshare (since the inconsistency allows each side to make a valid claim otherwise). Talk about defeating the point of having a standard! That's a foolish way to write a standard (you yourself said you don't do that) unless there happens to exist a dominant player and you are it, in which case, you have managed to split your competition field in half.. for each such inconsistency. Repeat over enough items of inconsistencies and you quickly leave the whole field behind. [We end up with a bi-/multinomial distribution where you are at the end that "got everything right" and most of the competitors land away from that end and within the fat middle.] I think Patrick was looking for specifics as to why this particular section warrants examples [specific reason to give an example here, or specific ambiguities that need be resolved]. Every example that resolves an ambiguity that might be very awkward to otherwise resolve, IMO, is a good example. [I have no opinion on 8.5.4 right now or I'd give it.] A handbook in addition to the standard would be a great idea, too. It's less problematic to fix mistakes in an unofficial handbook. Also, the market can allow the most clear writers to compete for the most accurate yet readable handbooks.