RE: [office] Differences between list proposals

["Mason, James David \(MXM\)" <masonjd@y12.doe.gov>]

 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:patrick@durusau.net] 
Sent: Wednesday, April 18, 2007 7:22 AM
To: Thomas Zander
Cc: office@lists.oasis-open.org
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!