RE: [xml-dev] Results of Open XML balloting at INCITS

["Rick Jelliffe" <rjelliffe@allette.com.au>]

G. Ken Holman said:

> I don't remember seeing any ISO/ITTF document stating in effect "none
> of what is said is a show-stopper".

Their actions. They did not stop the show. They did let the process continue.

Certainly, Standards Australia interprets it that way. In the invitation
to the meeting last week they wrote "The JTC1 process has established that
the ECMA-376 document is not contradictory to existing standards and ECMA
has responded to a number of technical considerations raised in the
initial consultation period." (Note of course that this includes not being
contradictory to ISO ODF, in the particular sense of contradictory
required for that 1-month period.)

>>The other thing to realize is that no means yes. When a nation gives a no
>>vote, they have to give the technical reasons why not and suggest their
>>preferred fixes.
>
> Not true ... a national body is not obliged to give technical reasons
> for a no vote.  National bodies and other voting members are welcome
> to vote no with non-technical reasons that have no resolution.  Their
> vote is counted as is all the others.  This was confirmed with JTC
> 1.  The comment about technical reasons only was misinformation
> disseminated at the Seoul plenary meeting of SC 34.

Glad to be corrected. There is that extra check box on the form, isn't there.

> I'm posting the following comments with my XML developer hat on and
> not in any official capacity regarding my standardization
> responsibilities.  As my private opinions on this matter were
> intentionally outed against my expressed wishes by one of the
> companies involved, I feel I can now comment openly with my own
> opinions about this situation.
>
> I see ISO/IEC 26300 ODF is an XML vocabulary for office documents.
>
> I see DIS 29500 OOXML is an XML vocabulary for office documents.

That covers the first paragraphs of their introductions, but not the
second paragraphs, where the rationales are quite different. For example,
ODF does not mention an archiving and preservation requirement but does
mention processability with XSLT.

> But think of a customer asking a developer to "please create an
> XML-based expression of this information I have that I would like to
> maintain in a spreadsheet application, and I don't care about the
> application but I do care about the data".  If there are no standard
> formats, the choice is muddy.  If there are two formats to choose
> from, a standard format and a proprietary format, the choice is
> clear.  If there are two standardized formats, the choice is muddy again.

Ask them to do the work in an ISO standard language: the choice will be
"muddy" because they then have to figure out which one is best to use. But
it is basic technical competence to understand the differences between the
major technologies available, not "mud".

> Therefore, to move forward the community should focus on new
> developments and what choices in standardization there are when a
> developer creates a new project or a vendor creates a new tool or a
> customer creates a new need.  There should be a clear choice to move
> forward and not a confusing choice to move forward.

So why have RELAX NG when we have ISO SGML DTDs (and XML DTDs, and XSD)?
And what can justify Namespace-aware DTDs? Don't they muddy? Just because
a standard has a niche does not mean it should not be a standard.

I think one part of the answer is that SC34 needs to put out a clear
guidance on where each of the various current and pending ISO standards
that can be used for documents: ISO SGML/DSSSL, W3C XML, ISO HTML, ISO
PDF/X, ISO PDF/A, ISO PDF/E, ISO ODF, ISO OOXML.  So that, for example, an
archiving organization might decide "We should use OOXML as the baseline
format for converting our legacy documents into XML, and then convert them
to ODF as our prefered long-term preservation version: but where an ODF
conversion is not satisfactory due to feature mismatch, the document has
to be kept in the baseline format until ODF or our ODF converters
improve."

We at SC34 need to get out of the application business and back into the
"enabling technology" business, and we won't do that by taking sides on
office formats.

Why not move forward by developing neutral sets of standards and profiles
at SC34 that all office and other developers can be tested against, for
example? Such as adopting the WAI accessibiliy requirements, or developing
clear CJK requirements? Or abstract test suites that can be used by NIST
etc to make concrete test suits? Or abstract application models, such as
the table in the back of ODF, that can be used as the basis of profiles
and so the basis of real interoperability? Or general definitions of
typesetting algorithms by their properties, to allow better algorithm
matching by receiving applications to allow closer page fidelity, which is
something users expect?

> The fast track process
> is not a standards development process but a ratification process and
> if it isn't clear that the specification can be ratified easily and
> without contradiction then the user requirements addressed by the
> fast track should have gone through a traditional open standards
> development process.

That is a good way to put it. But I don't think it is quite true.

If it were a mere ratification process, it would join the ISO process at
FDIS stage (i.e. one ballot), not DIS (ballot, fix, ballot), surely?
Furthermore it is a DIS which is created without the discipline of the ISO
idioms, so we shouldn't be surprised if there are more drafting issues
than we would expect from a DIS that came in from a Committee Draft.

Cheers
Rick Jelliffe