Blogs

Java-only reincarnation of odt2html (announce).


24 Oct 2007

Just released java incarnation of odt2html translator.
Source is published on odt2html.gradsoft.ua

Yet one correction of odt2html XSLT script


24 Oct 2007

Yet one correction of odt2html XSLT script from odf tools: better support for paragraphs with styles, derived from Preformatted20_Text style. Now it is possible to write text of program in ODF document, change color and expect, that all will be correctly viewed in HTML.

URL: for new archive: http://opendocumentfellowship.com/files/odt2html.xsl_0.tgz

AttachmentSize
odt2html.xsl.tgz4.75 KB

Dealing with cybersquatters


20 Jul 2007

Cybersquatting is illegal in many countries, even the US. The The Anticybersquatting Consumer Protection Act of 1999 covers the situation in the US. Enforcing rights in regards to trademark is one option. Apparently the use of the trademark or service mark itself is the act that confers ownership.

Next steps

Changes to odt2html.xsl


25 Jun 2007

I just made few changes in odt2html: implement
  a) PreformatettedText style ( <pre> environment in html)
  b) Programmlisting DOCBOOK style (according to Docbook template, supplied with OO).
insert-spaces template now really insert spaces.

File is attached to this message, I will be happy see one in next version of odftools.
URL is http://opendocumentfellowship.com/files/odt2html.xsl.tgz

AttachmentSize
odt2html.xsl.tgz4.37 KB

EOOXML -- What is a 'contradiction' at ISO -- Revisited


03 Feb 2007

The article that was on this page has been expanded, updated, and moved to http://opendocument.xml.org/node/238. Please correct your bookmark.

Sorry for the bother.

A story of TIFF


02 Feb 2007

I'd like to tell a story. It's a sad story. It's a story about a file format called TIFF.

TIFF was developed in the mid 1980s, as an attempt to get desktop scanner vendors to agree on a common image file format, rather than each company have its own proprietary format. In the beginning, TIFF was a simple format. And TIFF did what it was supposed to do.

But time passed. Scanners became more powerful, and desktop computer disk space became more plentiful. And TIFF grew to accommodate grayscale images, then color images. TIFF grew to accommodate Postcript. Some vendors wanted vector drawings, so TIFF grew to accommodate that too. TIFF grew to include multiple images, and even foreign file formats like JPEG. TIFF grew outside just images, to include clipping paths, for cropping, along with frames, layers and pages. It seemed like everyone wanted their own special tag in the TIFF spec. It was a format of absolute, 100% perfect fidelity. If you could describe it, TIFF could do it. Heck, you can even specify your preferred byte ordering in TIFF!

Gone were the days of data loss. TIFF marked a new era of absolute, loss-less image perfection. Everyone would use TIFF, and fidelity would be perfect. 100% fidelity. Always.

But as TIFF grew, more and more vendors felt unable to support all of it. TIFF became unmanageable. Its number of options, staggering. That's when vendors decided to implement interoperability subsets. They would pick and choose which parts of TIFF were relevant to them, and ignore the others. Some vendors could not implement LZW compression, due to its patent restrictions, so they didn't. Some vendors saw no need to support Postscript or vector graphics. Other vendors only wanted Postscript or vector graphics.

Interoperability subsets was TIFF's downfall. The mismatch in TIFF support through out "TIFF compliant" applications is staggering. And today, the only TIFF file that you can make and expect to work elsewhere is an un-compressed raw-data TIFF.

Don't be a TIFF.

EOOXML -- What is a 'contradiction' at ISO and what are its procedures? -- Updated


10 Jan 2007

NOTE: This article consolidates the research of several contributors. This page will be updated as further authorities are located.

With Ecma Office Open XML ("EOOXML") now in the "contradiction" phase at ISO/IEC, what does a contradiction mean in context? Here is some background on what a contradiction is according to JTC-1 Directives, along with a short discussion of relevant procedures and contact information. Apparently, there is no straightforward definition of contradiction within context, so one must read between the lines somewhat to arrive at a working definition.

Andy Updegrove has provided a condensed process overview at ConsortiumInfo.org:

Ecma is a "Class A Liaison" partner with ISO/IEC, which permits it to use the same Fast Track process that national standards bodies use. That process takes six months - the same amount of time that the PAS process takes (the route used by OASIS to submit ODF to ISO/IEC) – but has two steps rather than one, although the practical result is much the same.

During the first one-month step, any member may submit "contradictions," which, loosely defined, means aspects in which a proposed standard conflicts with already adopted ISO/IEC standards and Directives. Those contradictions must then be "resolved" (which does not necessarily mean eliminated), and these resolutions are then presented back to the members during the second stage to consider as part of the voting package. During this second, five-month step, other objections, questions and comments can be offered by members.

According to JTC-1 Directives, Edition 5, Version 2.0, section 13.4:

During the 30-day review period, an NB [national standardizing body] may identify to the JTC 1 Secretariat any perceived contradiction with other JTC 1, ISO or IEC standards. If such a contradiction is alleged, the matter shall be resolved by the ITTF and JTC 1 Secretariat in accordance with Section 13.2 before ballot voting can commence. If no contradiction is alleged, the fast-track ballot voting commences immediately following the 30-day period.

Section 13.2 uses the phrase, "ascertain that there is no evident contradiction", and 13.4 uses the phrase, "an NB may identify to the JTC 1 Secretariat any perceived contradiction" and 13.5 uses the phrase, "if a contradiction is alleged". The use of words like "evident", "perceived" and "alleged" clearly indicate that a NB may point out even the appearance of a contradiction.

Further, NB's are encouraged to be on vigilant about detecting and reporting such contradictions. In the Fifteenth Meeting of JTC1, held in 2000, the following Resolution 27, "Consistency of JTC 1 Products" was adopted:

JTC 1 stresses the strong need for consistency of its products (ISs and TRs) irrespective of the route through which they were developed. Any inconsistency will confuse users of JTC 1 standards and, hence, jeopardize JTC 1's reputation. Therefore, referring to clauses 13.2 (Fast Track) and 18.4.3.2 (PAS) of its Directives, JTC 1 reminds ITTF of its obligation to ascertain that a proposed DIS contains no evident contradiction with other ISO/IEC standards. JTC 1 offers any help to ITTF in such undertaking. However, should an inconsistency be detected at any point in the ratification process, JTC 1 together with ITTF will take immediate action to cure the problem.

From that passage we can deduce that confusion of users, loss of reputation and lack of consistency with existing standards can be aspects of a contradiction. Note as well the WTO's Agreement on Technical Barriers to Trade Annex 3(H), Code of Good Practice for the Preparation, Adoption and Application of Standards states:

The standardizing body within the territory of a Member shall make every effort to avoid duplication of, or overlap with, the work of other standardizing bodies in the national territory or with the work of relevant international or regional standardizing bodies.

So we can add duplication of or overlap with existing standards to our list of admissible aspects of a national body's contradiction. To sum up, an ISO contradiction may be based at least on:

  • confusion of users;

  • damage to ISO reputation;
  • lack of consistency with existing standards;
  • duplication of existing standards; and
  • overlap with existing standards.

Plainly, the term is given a broader meaning at ISO than is given in formal logic.

One obvious Office Open XML contradiction would be against ISO/IEC JTC1 26300 "Open Document Format for Office Applications" ("ODF"). According to the ODF specification, section 1.1:

This document defines an XML schema for office applications and its semantics. The schema is suitable for office documents, including text documents, spreadsheets, charts and graphical documents like drawings or presentations, but is not restricted to these kinds of documents.

Compare that to the Office Open XML specification, Part I, section 1.1:

This Part is one piece of a Standard that describes a family of XML schemas, collectively called Office Open XML, which define the XML vocabularies for word-processing, spreadsheet, and presentation documents, as well as the packaging of documents that conform to these schemas.

Office Open XML unquestionably duplicates or at least significantly overlaps with the ODF specification; moreover, unlike Office Open XML, OpenDocument incorporates still other standards such as XLinks, SVG, XForms, MathML, and Dublin Core metadata. In contrast, Office Open XML reinvents the wheel at every turn rather than relying on existing open standards. Such problems are sometimes insurmountable; for example, EOOXML requires use of bitmaps but XSL does not provide bitwise operators. Therefore, data loss in XSL transformations from EOOXML to other formats is unavoidable. That problem creates a contradiction in the ISO sense; full fidelity in automated translations between OpenDocument and Office Open XML is infeasible given this serious deficiency in the latter. [1] [2]

Having two contradictory and inconsistent standards for the same problem would only cause user confusion and lack of interoperability. It will also drive up both user and developer expenses, frustrating the ISO goal [PDF] of "one standard, one test, and one conformity assessment procedure accepted everywhere.”

A highly relevant precedent is ISO's derailment of the WAPI standard proposed by the Chinese government that was a candidate for fast-track voting. In that matter, the primary contradictions were submitted by the IEEE. The IEEE's relevant documents can be found here and provide good examples of successful contradiction submissions. Note that the information raising the contradiction must be detailed and referenced; a short statement such as that above will not suffice. Also note that IEEE was not hesitant about pointing to other warts with the WAPI proposal and to its unfair effect on developers and end users.

Moreover, much of the IEEE criticism focused on the general unavailability to developers of a communications protocol that was incorporated by reference. That, of course, is a huge issue in regard to Office Open XML because of its relationship to the Microsoft Office binary file format whose secret specifications are incorporated by reference. All of those binary blobs, Windows bitmaps, and application-specific metadata tags are apparently fair game as well.

Other grounds may be raised as part of the objection. For example, JTC-1 Directives also provide:

11.1.2 A P-member of JTC 1 or an SC may appeal against any action, or inaction, on the part of JTC 1 or an SC
when the P-member considers that such action or inaction is:

  • Not in accordance with these directives; or
  • Not in the best interests of international trade and commerce, or such public factors as safety, health or environment.

The allowance of such factors in appeals implicitly authorizes them to be raised by NBs at the objection phase.

The voting "P" member national bodies of JTC1 are listed here.
The national bodies' contradictions must be received by the Secretariat of JTC1 by the deadline on February 5, 2007. The current secretariat is held by Mrs. Lisa Rajchel of ANSI. Her contact information is here.


Notes

[1] See e.g., Wikipedia Wikipedia description of XPath:

XPath (XML Path Language) is an expression language for addressing portions of an XML document, or for computing values (strings, numbers, or boolean values) based on the content of an XML document.

The XPath language is based on a tree representation of the XML document, and provides the ability to navigate around the tree, selecting nodes by a variety of criteria. In popular use (though not in the official specification), an XPath expression is often referred to simply as an XPath.

[2] See also Wikipedia description of XSL transformations:

XSLT is a specific kind of template processor primarily designed to "transform" XML documents into other XML documents. The original document is not changed; rather, a new document is created based on the content of an existing one.[3] The new document may be serialized (output) by the processor in standard XML syntax or in another format, such as HTML or plain text.[4] XSLT is most often used to convert data between different XML schemas or to convert XML data into HTML or XHTML documents for web pages, or into an intermediate XML format that can be converted to PDF document

. . .

XSLT relies upon the W3C's XPath language for identifying subsets of the source document tree, as well as for performing calculations. XPath also provides a range of functions, which XSLT itself further augments. This reliance upon XPath adds a great deal of power and flexibility to XSLT.

Microsoft/Ecma's submissions to ISO for Ecma Office Open XML


10 Jan 2007

Microsoft (technically Ecma International) has initiated the ISO standardization process for Ecmas Office Open XML, Microsoft's response to requests that it support the OpenDocument standard. The attached documents were sent by Emca to all JTC1 members in addition to the specification. The specification itself can be downloaded here, or in hunks from here. (Very large documents alert.)

In particular I'll draw your attention to JTC001-N-8455-4.pdf. This is a summary whitepaper where Ecma makes the case for why this is a wonderful standard. At 17 pages in length, I'd expect that most national body members will read this and nothing else. It contains such effusive praise as:

4 PROPERTIES OF THE STANDARD

This section prepares you to investigate OpenXML by describing some of its high-level properties. Each subsection describes one of these properties and refers to specific features within OpenXML.

.... “Interoperability” describes how OpenXML is independent of proprietary formats, features, and run-time environment, allowing developers a broad range of choices.

.... “Internationalization” mentions a few representative ways in which OpenXML supports every major language group.

.... “Low Barrier to Developer Adoption”, “Compactness”, and “Modularity” list specific ways in which OpenXML avoids or removes practical impediments to implementation by diverse parties: learning curve, minimum feature set, and performance.

.... “High Fidelity Migration” describes how OpenXML meets the over-arching goal to preserve the information, including the original creator’s full intent, in existing and new documents.

.... “Integration with Business Data” describes how OpenXML incorporates business information in custom schemas to enable integration and reuse of information between productivity applications and information systems.

.... “Room for Innovation” describes how OpenXML prepares for the future by defining further extensibility mechanisms and providing for interoperability between applications with differing feature sets.

Low barrier to adoption? Compactness? Prepares for the future? My brain brings to mind a specification of over 6,000 pages that can only be implemented by a single vendor and a covenant not to sue that grants rights (if any at all) only for the current version of the Ecma specification. Might one suspect that someone forgot to get their annual spin innoculation?


The full and official specification for EOOXML can be downloaded here. The accompanying documents are downloadable from this site and linked below.

AttachmentSize
JTC001-N-8455-4.pdf178.8 KB
JTC001-N-8455-3.pdf14.41 KB
JTC001-N-8455-2.pdf24.99 KB
JTC001-N-8455.pdf82.3 KB

ODF Viewer submitted to software lists


31 Dec 2006

I have submitted the ODF Viewer to the following sites:

http://freshmeat.net/ -- listed
http://opensourcemac.org/
http://opensourcewindows.org/
http://www.versiontracker.com/ (both Mac and Windows sections) -- listed
http://osx.hyperjeff.net/Apps/
http://www.autopackage.org/packages/

Some (Alex or Daniel, probably) previously added it to this page:
http://developer.mozilla.org/en/docs/XULRunner_Hall_of_Fame

I will update this blog entry as I do more submissions.

ODF Viewer: increase in site traffic


31 Dec 2006

I registered the ODF Viewer at freshmeat.net on 27 December.

Not surprisingly we had a big jump in hits on our website after that. Here's a summary of recent traffic:

Views of odfviewer page:
25/12: 37 (4%)
26/12: 30 (6%)
27/12: 558 (39%)
28/12: 120 (14%)
29/12: 110 (13%)
30/12: 64 (10%)

referred from freshmeat.net:
27/12: 257 (74%)
28/12: 38 (23%)
29/12: 15 (9%)
30/12: 3 (3%)

unique visitors:
25/12: 162
26/12: 185
27/12: 477
28/12: 263
29/12: 284
30/12: 198