Cart
[Home] [By Thread] [By Date] [Recent Entries]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
