[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office] Differences between list proposals
I want to second some of Patrick's points from an ISO point of view. The primary purpose of JTC1 standards is to promote interoperability. I'm now in my 27th year of working on JTC1 standards, and my experience has that the successful standards have been the ones that were out in front, leading the way towards correct behavior. The proposals that I've seen that simply codified existing behavior were too narrow and generally failed (does anyone other than me still remember the Navy Document Interchange Format from about 1984?). Standards shouldn't be too far out ahead; that was one reason ODA (ISO/IEC 8613) failed. It took off ahead of the tecnology, and nobody implemented it. SGML (ISO/IEC 8879) grew out of user experiences; it was ahead of technology, but not so much that implementations couldn't grow with the standard. And there were commercial products being developed, often by members of the committee, along with the standard. (This is also the model in the IETF: there must be implementations growing along with an RFC for the standard to progress.) Both ODA and SGML were justified to ISO by being interchange technologies. ODA was only an interchange format: it would have been almost impossible to write directly. SGML (and thus XML) was unusual in that we tended to edit it directly and use it as the internal format for storage of documents. That wasn't a primary design requirement but was rather an outgrowth of our habits of editing older generic coding (e.g., GML, the input languages to TeX and troff) directly. (We did specify that the data stream had to be human readable, but that didn't mean documents had to be edited that way.) SGML structured editors grew out of language-sensitive editors for programming languages, rather than word processors, because most of the standards team were programmers and knew that kind of editor. But there's noting intrinsic about SGML/XML that requires documents to be edited or stored that way. Today's structured editors of XML that are designed for end users (e.g., FrameMaker, Arbortext) stick close to the older models for SGML editors not so much to expose the coding to the user as because their primary user community is working with highly strucured documents and need the structured editing environment, whether XML is there or not. Both ODF and OOXML owe about as much to the ODA model of word processors as they do to the SGML/XML tradition. There's nothing that says that documents need to be edited in those formats, just that they need to be interchanged in XML. The question for the standards process then becomes whether the XML format has a life of its own or instead just models the internal workings of some existing product. I think what we're seeing in ODF is that we're discussing how the XML interchange format works, and then the products can catch up with it. My impression is that the opposite is true for the other proposal. My personal feeling is that the ODF process is closer to what JTC1 expected. Jim Mason -----Original Message----- From: Patrick Durusau [mailto:firstname.lastname@example.org] Sent: Wednesday, April 18, 2007 7:22 AM To: Thomas Zander Cc: email@example.com Subject: Re: [office] Differences between list proposals The question is whether standards should 'bless' current behavior or do standards establish what the 'correct' behavior should be. The dividing line is rarely clear because standards exist in tension with implementations, save for the rare cases where standards precede all implementations. Being something of a professional standards person, I tend towards standards establishing 'correct' behavior so that the process is not trapped by the particular implementation choices. Some people with equally long if not longer experience in the standards process do take the opposite position. If some implementation has made choices that are contrary or inconsistent with the eventual standard, then that implementation has to change to be consistent with the standard. I am very reluctant to accept the position that standards should be adapted to meet the choices of a particular implementation. Particularly if that will lead to different ways to model the same behavior, which will lead to a lack of interoperability, the very thing that standards are written to promote (well, one of the goals of standards). Hope you are having a great day! Patrick -- Patrick Durusau Patrick@Durusau.net Chair, V1 - Text Processing: Office and Publishing Systems Interface Co-Editor, ISO 13250, Topic Maps -- Reference Model Member, Text Encoding Initiative Board of Directors, 2003-2005 Topic Maps: Human, not artificial, intelligence at work!