Re: [office] Additional Ballot Comments (China)

["David A. Wheeler" <dwheeler@dwheeler.com>]

Quick background, for those who weren't on the teleconference today:
We have the official comments from ISO about OpenDocument Format,
and they've all been carefully examined. However, there is a rumor
that China had submitted comments to ISO, and that somehow
their comments didn't get into the transmission from ISO to OASIS.
We (OASIS TC members) have no way of knowing if this is true
or not, and it's hard to respond to comments we don't have anyway :-).
Robert Weir had some text that _might_ be the Chinese comments
or an early draft of them. We certainly _DO_ want to respond to
concerns from China, if there are any. We don't know if the text he has are
actually China's comments, though; there might not even BE comments
from China. So Weir posted to this group what he had,
with the caveat that this may not be China's comments.

Robert, thanks for sending us the informal text that _might_ be
China's comments (or an early draft of them)
on the Open Document Format (ODF).
Whether or not they are China's comments, it'd be worth briefly
running them down. That way, we'll be better-prepared to
support any issues China has.

Here are my quick thoughts on the comments. In short, I think
many of these comments don't have enough detail for us to be
able to usefully respond, or reflect a misunderstanding about ODF.
The latter are actually encouraging; if there is some misunderstanding,
then we can reply with a clarification that might be very helpful to them.
It may be that these were the draft comments, and that there
was a scrubbing process that eliminated them before they were
formally sent to ISO. I think we should try to see if there WERE any
"lost" comments so we can get them quickly, but we've already delayed
once. We could wait forever for comments that may not exist.

robert_weir@us.ibm.com wrote:
>
> 1. Considering the market relevance, ODF should be integrated with 
> China national standard final draft — Uniform Document Format (UOF) as 
> much as possible, as well as Microsoft’s Open XML Format.
I don't see how the TC can usefully respond to this without more 
information,
because it isn't clear at all what "integrated" means.
Certainly we all agree that one standard format for document interchange 
between
arbitrary products, with no royalty or other legal restrictions, would 
be best.
But let's look at the two formats mentioned.

"Open XML" (OXML) is still in flux, so it is hard to justify changing TO 
something
that is still in flux or may even be abandoned (ECMA's Java standardization
group, for example, was abandoned after much money and time was spent).
In essence, Microsoft decides what it is and what it will be changed to 
become.
This format avoids reusing many relevant standards, choosing nonstandard
proprietary approaches instead (such as a proprietary
packaging format that may require special licensing), and it would NOT
be wise to move in that direction. Many believe it
is essentially a document to define how to interoperate with one specific
vendor product; again, not desirable for a standard defining interchange
between arbitrary products. Many OASIS OpenDocument TC members
have been trying to get the groups to work together (I've tried to do so!),
but ECMA and Microsoft have expressed little interest in cooperation so far.
Maybe this will change, I hope so. For a comparison of the formats, see:
http://www.groklaw.net/article.php?story=20051125144611543

I don't have much information on "Uniform Document Format" (UOF); the
little I could find in English is here:
http://www.y-adagio.com/public/committees/docsii/doc_50-99/symp_bnkk/china.pdf
Both OpenDocument and UOF are designed to be completely open and implemented
in programs without restrictions, royalty-free, and with no legal bindings.
However, OpenDocument is designed to work for all languages; the stated 
purpose
of UOF seems to only cover Chinese documents, and there is no effort 
identified
to make it an international standard. Thus, there is STILL a need for an 
international standard,
such as OpenDocument (ODF).

 From a quick glance at the document, it appears that OpenDocument should be
able to support UOF documents at the high level.
They have similar concepts about styles,
different document types, etc. OpenDocument represents
the culmination of MANY years of work, for MANY languages and after
examining many implementations, so I expect that UOF documents
should be mappable to ODF. For example, the heading system
of OpenDocument appears MUCH more flexible than the chapter/section system
of UOF. I don't have time or detailed English-readable information to do 
a deeper
analysis, but there is no OBVIOUS complete disconnect from a few 
moments' look
that would make ODF incapable of representing UOF at a high level.

More generally, the concerns about OpenDocument seems to be either
incorrect or non-critical. E.G., it has a table claiming that OpenDocument
is "not modifiable", which is clearly not true - OpenDocument files
CAN be modified, that's the point, and OpenDocument also supports 
extensions.
It also claims that there are "too many attributes"; this is a personal
taste issue, since attributes are a standard part of XML and work very well.

It may be that their concerns are due to misunderstandings about ODF,
rather than any particular problem with ODF.

Clearly if China wishes to have a national standard, it is sovereign and 
can do so.
A quick glance suggests that it should be relatively easy to convert between
UOF and ODF, and only ODF is designed to serve
as an international standard. If there are problems in
the transformation, I think we'd all like to know what they are, but absent
more specific information it's difficult to see a problem.

> 2. XSLT Style sheets should be provided to facilitate the conversion 
> among the mainstream document formats.
That is not possible with OXML yet, since there is no OXML standard
(and might never be).

This page: http://en.wikipedia.org/wiki/OpenDocument_software
lists many software packages supporting ODF.

Here is a Docbook to ODF XSLT:
http://sourceforge.net/projects/docbook2odf

As far as HTML/XHTML goes, that is already available:
http://books.evc-cit.info/odf_utils/odt_to_xhtml.html

According to:
http://opendocumentfellowship.org/Main/CurrentActivities
"J. David Eisenberg is working on an XSLT transformation to convert 
OpenDocument files into HTML." 
<mailto:odf-devel-subscribe@opendocumentfellowship.org> 
<https://addons.mozilla.org/extensions/moreinfo.php?id=1888&application=firefox>

More generally, there are a large number of packages that do document 
conversion,
some using XSLT, some not.

> 3. UNO implementation of ODF should conform to CORBA specification.
OpenDocument neither mandates nor forbids CORBA. ODF is a document
format, not an RPC system, so it can be used in any system that processes
documents, whether it uses CORBA or not.

Presumably, this is a reference to OpenOffice.org, which is one of the
implementations of ODF and has a subsystem called "UNO".
This is a comment that should be directed at
the OpenOffice.org project, since this is an implementation issue.
Other implementations, like KOffice, don't have UNO; UNO is
not in scope.

I think this is a simple misunderstanding of the scope of OpenDocument.
OpenDocument is a document format standard, not an RPC standard,
so CORBA is out of scope.

> 4. ODF in W3C schema should be provided in addition to RelaxNG 
> specification.

I respectfully disagree.

Relax-NG is an ISO standard (as well as an OASIS standard), so there
is no reason to prefer XML Schema from the point-of-view of standards 
procedure.

And Relax-NG is technically superior. Many constructs that
Relax-NG can express easily are difficult or impossible to express in 
XML schema,
PARTICULARLY the ones most important in a standard for document interchange.
A short comparison is here:
http://www.xmlhack.com/read.php?item=1677
For example, Relax-NG directly supports strong support for unordered 
content,
while XML Schema does not; this weakness of XML schema is not a problem
for databases expressed in XML format, but is a serious weakness for
expressing arbitrary documents (the WHOLE REASON for OpenDocument).
Relax-NG has a clear, unambiguous notion of validity and its validation 
process
clearly separates the schema from the instance; this is important for 
validating documents
of the kind considered by OpenDocument. Relax-NG is also easier to 
understand,
and shorter generally; the OXML spec is longer in part because of this.

If someone wants to create a non-normative translation of the Relax-NG 
specification
into XML schema, that's fine. But such a translation would necessarily lose
some of the requirements, so it would need to be non-normative.

In short, there are several different schema definition standards, and
for this kind of work, RELAX-NG is the appropriate standard; XML Schema 
is not.

>
> 5. The document structure should be described by means of hierarchical 
> elements for better extensibility, whereas the current version uses 
> too many attributes.
If I understand this comment correctly, hierarchy has
the advantage of being simple, but the disadvantage of being inflexible.
ODF is designed so that it can handle very complex documents
which may not be representable (or easily representable) in a strict 
hierarchy.
Yes, this introduces slightly more complexity, but since there are already
multiple implementations, this is obviously not insurmountable.

I may be misunderstanding this comment, I'd love to hear more.

> 6. ODF should add in support for user defined XML data.
It's already there, but in a different way than perhaps you were expecting.
This may also just reflect looking at very old versions of ODF, instead
of the final form.

The European Commission requested support for “custom schemas”
into ODF. The "simple" way to do that (e.g., Microsoft's) yields documents
that are difficult to interchange properly between different products,
and that ruins the whole point. Daniel Vogelheim recommended adding XForms
to ODF during its development process.

ODF now has embedded support for a subset of the XForms standard.
XForms add the capabilities typically desired for custom schemas, which 
were requested by Europe, but without the horrific interoperability 
problems that uncontrolled custom schemas can cause. Gary Edwards 
reports, “It turns out that XForms is an elegant solution to the ‘custom 
defined schema’ problem, able to address both the “collaborate with 
yourself” ... model, and, the infinitely more important shared business 
process schema model. The binding model in XForms is extraordinary... we 
were quite unaware of this potential [at first]... [but once we began to 
understand it] oh what a treasure we found.” In particular, its approach 
manages to be portable among many different systems, and not tied to any 
one. XForms is also a standard in its own right, which is a good thing; 
it’s generally a very good sign if a standard tries to reuse existing 
standards instead of recreating its own incompatible components.


As a completely different approach, since the ODF format is
usually exchanged as a zipped file, you
could also simply include an XML file in the zip file, and refer to it.
The XML would be outside the standard, though, and there's no
normal reason to do that.

> 7. Different compression algorithms should be adopted according to 
> different media types appeared in the content rather than using ZIP only.
ZIP is a higher-level wrapper format that can support many different
compression algorithms. So the specification as written can support
many different compression algorithms, as requested.

A particular compression algorithm must be implemented by all,
to support arbitrary exchange (when you don't know all the capabilities
of the receivers).

> 8. Extension facilities should be provided for particular software 
> products to allow them use product specific features.

Already in ODF.
> 9. Text table is hard to transform into other formats due to its 
> faulty design.
This is too vague to be reasonably commented on.
What "faulty design"? It's based on well-known and widely-used
standards, with no "faulty designs" noted in them.

> 10. Representation of graphics and chart is imperfect, e.g., the 
> incompact chart description in spreadsheet.

Too vague, need more detail.

> 11. Field representation is inexplicit and incomplete.
Too vague, need more detail.

> 12. Some values adopted are not described clearly in the standard 
> document, e.g., some string and enumerate values.
Too vague, need more detail.

> 13. International markup. i.e., multilingual and localized tags should 
> be supported.
Additional tags are permitted. However, there must be an agreement on the
names for tags of standard values, and the tags that had already been 
proven in
use were used as the starting point.
> 14. Function related to Chinese processing should be enhanced, e.g., 
> to support binding lines and diagonally divided table cells.

I'm not sure I understand this comment, but let me try. Cells can have 
diagonal lines, see 15.11.8; however they are simply lines (they do not 
divide cells into two different sub-entries). It might be possible to do 
the same with a graphic object and wrapping.

These sound like useful enhancements. However, since this is expressed 
as a "should" and as the last item on a long list, these sound like 
nice-to-have additional features for a future version, rather than 
critical features that prevent use of the format. I would urge the 
Chinese to participate and extend a later version of OpenDocument to add 
these capabilities.

Anyway, this is a first attempt. I may have misunderstood some of the 
comments;
this is a first try.

--- David A. Wheeler