[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] Additional Ballot Comments (China)
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]