|
2008-09-28, 22:34
ODF – Our work here is done?
Day 0 had been concluded with a tasty Korean meal (washed down with possibly a tad too much Korean vodka) and it was very interesting to hear some of the views from NB members on how they thought the office formats future will play out (and no, there were no Microsoft, IBM or Ecma people at the table). One view was that ODF had served its purpose (to get MS formats out into the open) and should now declare victory before fading away gracefully; another was that OOXML would surely become the default format of the OpenOffice.org suite, and that this would crystallize the real option users had: to use FOSS or commercially-licensed Office packages. I’m not sure I’d go with either of these but still, it was refreshing to get some new perspectives rather than the stale repetitions that have too often characterised the exchanges of the past months. It will be interesting to see what really happens ... personally I think ODF is more likely to emerge as a kind of “default choice” than OOXML (not perhaps, that most users care).
Into the meetings proper
Sunday (Day 1) was a busy day of WG 1 meetings in the excellent facilities provided by our Korean hosts. In the morning we covered a number of DSDL topics, including Part 8 (DSRL) and the part I am editing – now called “Extensible Datatypes” – which has a new draft which will progress to FCD ballot. Rick Jelliffe, who sadly isn’t with us, had sent a voice message talking us through his fascinating proposed enhancements to Schematron – the Part of DSDL for which he is responsible. Very much business as usual for WG 1. However …
OOXML shock?
The afternoon was devoted to OOXML matters. Evidently, the sudden appearance of the final text of ISO/IEC 29500:2008 has come as something of a surprise for many; and the appearance of the first defect report (from Japan) shortly thereafter was a shock. Suddenly it’s all real; the clock is ticking and the Project Editor is obliged to respond to Japan’s report in eight weeks. Murata Makoto (the convenor of WG 1) carefully explained the details of the maintenance regime and took us through an example of one of the Japanese defects, which centred on a BRM-mandated change (from Finland) that had not been properly implemented in the final OOXML text. No doubt other NBs, as a priority, will now scour OOXML to make sure “their” changes have been implemented, and submit defect reports accordingly where they have not. The UK, with its 600 or so accepted changes, has a lot of checking to do …
I look on this though with a certain grim satisfaction, for two reasons. First because by insisting on timely defect handling SC 34 is compensating for a deficiency of the Fast Track process: the lack of National Body review of the final text. Secondly because one of the many problems of the JTC 1 standardisation of ODF in 2006 is the lax maintenance regime, which boils down to OASIS declaring: we’ll fix your reported ODF defects if we want to in our own good time, thank you very much. Partly as a reaction to this SC 34 was determined to hold OOXML’s feet to the fire and make sure the JTC 1 maintenance regime (one of the better processes described by the Directives) was fully applied and that this time, it was got right.
|
stumble this |
digg it!
|
|
2008-09-29, 16:46
I was rather surprised to read in your ather post that the final text wasd already fixed and no defects can repaired anymore. As I read it ITTF can propose changes to the text if they are considered nescesary in the fastracking publication phase of the international standard:
From the JTC1 directives 13.14
If modifications are considered necessary, the ITTF editor shall submit proposals for modification to the Project Editor for approval. No IS shall be published without such approval. ITTF shall prepare a proof of the IS and send this to the Project Editor for endorsement including identification of the changes made. The only changes permissible at this stage are corrections of recognised errors in the revised text or errors introduced by ITTF in preparing the proof. ISO/IEC JTC 1 Directives, 5th Edition Version 3.0, 62 Upon receipt of the endorsed proof from the Project Editor, ITTF shall make any final corrections required and proceed with publication of the IS (or amendment).
So at this point the ITTF should still be in charge of determining whether or not the submitted defects by national bodies require nescesary modifications or if they can leave it to errata, amendments and maintenance.
|
|
2008-09-29, 20:56
@HalThere have been rounds of discussion between the ITTF editors and the project editor (as you describe); that has now concluded to produce a text for publication. There needs to be a fixed text at some point or readers will not be sure of the status of what they are reading. As far as ITTF are concerned, the text is correct.
Defects noticed by NBs are sent to SC 34 and need to be processed by the mechanisms described in the JTC 1 Directives which include assessment (it is quite common for reported problems to tun out not to be problems on closer inspection), and which may ultimately produce corrigenda which NBs will vote on. The ITTF cannot act as a surrogate for this fuller maintenance activity and it would be unprecedented for ITTF to enter into direct assessment of NB contributions.
- Alex.
|
|
2008-09-29, 22:54
I undeerstand your point.btw
My IE8 beta 2 version serieusly dislikes your sites javascript.
|
|
2008-09-30, 16:59
ODF and OOXML are like paper-tape and punch-card.You can say mostly the same things on both. But those sequence numbers on columns 73 to 80 of a punch-card. Do you reproduce them onto a paper tape ? They serve no purpose on paper-tape, but if you drop a deck of cards they significantly reduce the cost to get the FORTRAN written on them working again.
And what do you do with a 200-character line on paper tape ? Do you break it into 3 cards, and put continuation characters in column 6, like FORTRAN ? Or not ?
IBM's still making money on the back of punch-card formats. Everyone else in the industry (and a lot of IBM, too) is on paper-tape formats now. ASCII, then UTF8.
I expect only Microsoft will go for OOXML; and anyone who's financially dependent on them, of course. Give it 50 years, it will die out. But it will take that long.
|
|
2008-10-01, 18:59
Isn't OOXML so much more complicated to implement than ODF and therefore more likely to have defects and incompatibilities and to be more expensive? I don't know why anyone would have anything to do with it that wasn't paid to. But I guess that's the whole point here. I know I won't be using OOXML...
|
|
2008-10-01, 20:48
Interesting how OASIS got framed here with;
many problems of the JTC 1 standardisation of ODF in 2006 is the lax maintenance regime, which boils down to OASIS declaring: we’ll fix your reported ODF defects if we want to in our own good time
In fact there is a lot of review and *OPEN* participation going on within OASIS which I can confirm as one of those FOSS-developers who participates there and within last years every single issue we came up with got solved rather fast.
Do I really need to add that we are not allowed to participate in *any* kind (what includes review-processes) at those OOXML-standard? Heck, it was even not publish at all while all the work, the drafts and the communication is done public accessible in the open at OASIS.
Sebastian Sauer
KOffice hacker interested in open standards and interoperability.
|
|
2008-10-02, 07:05
@SebastianActually when OOXML was being developed in Ecma they published three drafts and actually submitted one of those drafts to IS/IEC JTC1 about 7 month before submitting the format to ISO/IEC.
(Office Open XML, working draft 1.3, May 2006)
Also KOffice is very likely a welcome participant at Ecma (as is the Gnome foundation already) and unlike in OASIS where every descision in the TC has to be approved by the IBM and Sun majority each organisation has only one vote in participations.
|
|
2008-10-02, 13:57
@Sebastian,yes OASIS is one of the most open consortium standards organizations, no question here. But at the same time OASIS ODF TC was very lax in responding to SC34 defect reports about ODF.
I don't know why you are talking also about OOXML here and whom you mean by *we*. But for example in Czech Republic anyone was able to take part in OOXML review process with access to all documents. Even some Czech OpenOffice.org people was taking part in comment process here.
Jirka
|
|
2008-10-08, 23:12
@hAlLet's look...
1. The OOXML specs are still top secret and to publish them is copyright violation. Conmpare that with OpenDocument 1.2 draft7
2. How much of those thousand of raised problems got addressed in OOXML?
3. Is SC34 open too and not read-only?
@Jirka
"I don't know why you are talking also about OOXML here"
Cause OpenDocument and OOXML are topic of this blog.
"whom you mean by *we*"
Probably anyone who's interested in vendor-neutral standards.
"anyone was able to take part in OOXML review process"
Right. What did happen to the provided feedback? It does not help to collect them and ignore them. They should have been addressed *before* we got into the backward-compatibility trap. Next try, OOXML 2.0...
|
|
2008-10-09, 07:23
@Sebastian> The OOXML specs are still top secret
They are not "secret"; they are being prepared for publication.
> and to publish them is copyright violation. Conmpare
> that with OpenDocument 1.2 draft7
ISO/IEC 26300 was produced the same way as 29500 is being now.
OASIS Standards are also copyright documents distributed under the terms of a license which forbids, among other things, any modification of the document.
> How much of those thousand of raised problems got addressed in OOXML?
All were addressed; all were resolved (at the BRM), to the evident satisfaction of the International stakeholders.
> Is SC34 open too and not read-only?
The WG's have public mailing lists, and SC 34 is open to participation from any National Body. National bodies have their own mechanisms for collecting public comments and/or appointing representatives for formal participation.
|
|
2008-10-09, 09:11
>> The OOXML specs are still top secret > They are not "secret"; they are being prepared for publication.
That's exactly the point and one of the fundamental problems. To be "open" includes to act open at each single step of the whole process what includes review of drafts (aka things prepared for publication) and decision-making. Review *before* the final
publication wents out is essential cause else it's to late. To be limited into a read-only but don't touch role is not enough. To be allowed to report typos and maybe even fix them is not enough either. To be "open" includes real participation, fixing problems as soon as possible *before* they went final.
Let me provide you here a concret sample how "open" works within OASIS vs SC34. Sorry for being such offensive here, but we (ppl like me who expect vendor-neutral standards) do know pretty well the difference cause we are dealing with it every single day.
>> and to publish them is copyright violation. Conmpare
>> that with OpenDocument 1.2 draft7
> ISO/IEC 26300 was produced the same way as 29500 is being now.
See, I am developer and I actually have to deal with the reality rather then what's written on papers or communicated via PR-companies. The results are not the same and that's what counts for me. We may like to discuse why that's the case but I guess I did provide already a valid point above that is at least part of the problem.
>> How much of those thousand of raised problems got addressed in OOXML?
> All were addressed; all were resolved (at the BRM)
Wow. Yes, we are looking from it from different point of views. For me a problem is not an item on a checklist that can be solved by marking it as solved. For me a problem prevents me to do something in an effective way like e.g. developing a solution.
>> Is SC34 open too and not read-only?
> SC 34 is open to participation from any National Body.
right, "open" but...
|
|
2008-10-09, 09:54
@Sebastian> Review *before* the final publication wents out is
> essential cause else it's to late. To be limited into a
> read-only but don't touch role is not enough. To be
> allowed to report typos and maybe even fix them is
> not enough either. To be "open" includes real participation,
> fixing problems as soon as possible *before* they went final.
There needs to be a cut-off point somewhere, and I have written before how the Fast Track would benefit from an FDIS stage.
However, despite the text having been leaked all over the web, I'm not seeing many reports of defects yet. Maybe it's near-perfect?
It is not too late to fix things either: OOXML is now being maintained by SC 34. Faults will get reported and fixed. Find something? contact your NB and report it.
(This rather contrasts, BTW, with OASIS's recently-invented errata mechanism, which refuses even to acknowledge that a published OASIS standard can even *have* faults, by outlawing the application of any substantive change in errata).
> See, I am developer and I actually have to deal with the
> reality rather then what's written on papers or communicated
> via PR-companies.
Well, snap. I am a developer who's company has been burned by MS's inability to keep their MS Office document formats open, documented and stable. For the first time ever, we now have that prospect. Sounds good to me!
> Wow. Yes, we are looking from it from different point of
> views. For me a problem is not an item on a checklist that
> can be solved by marking it as solved. For me a problem
> prevents me to do something in an effective way like
> e.g. developing a solution.
I have been involved in several projects that developed solutions around Office's XML: the harder, 2003 version. OpenOffice.org reads OOXML (Ecma 376) documents. So, it was/is already possible, as a matter of fact, to develop solutions around these formats.
In future, the standardisation of OOXML will make developing these solutions easier.
> right, "open" but...
Any human organisation needs to set a quality bar and have its own internal checks and balances. Or do you expect to be able to pick up the phone to Linus Torvalds and dictate new code for the Linux kernel? Open does *not* mean indiscriminate.
- Alex.
|
|
We are sorry. New comments are not allowed after 30 days.
|
stumble this |
digg it!
|

Categories





