a 'mooh' point

clearly an IBM drone

Re-introducing on/off-values to ST-OnOff in OOXML Part 4

23. juni 2009 18:57 / jlundstocholm / Generel Comments (9)

At this very moment we are discussing re-introducing the values on/off to the simple type ST_OnOff in the transitional part of OOXML.

Background:

Some countries (including Denmark and UK) argued during the DIS29500-process that the enumeration values "on" and "off" of the simple type ST_OnOff were inappropriate since they expanded the W3C Schema data type xsd:boolean. So at the BRM, these values were removed from the simply type ST_OnOff.

Now, that's all fine and dandy - only problem was that it made (according to a Microsoft estimate) 90% of all existing documents (and existing applications) non-conformant. Alex Brown demonstrated this in his article "OOXML and Office 2007 Conformanc: a smoke test". Further, it went directly aganst the scope of IS29500:2008 which was to "represent faithfully the existing corpus of word-processing documents, spreadsheets and presentations that have been produced by Microsoft Office pplications (from Microsoft Office 97 to Microsoft Office 2008, inclusive)".

So we have been disussing this quite a bit - because by re-introducing the values on/off would effectively be reversing a BRM decision ... in other words ... politically, it is a bit of a hot potatoe.

You might argue that this is a prime example of how Microsoft controls SC34/WG4 and how we simply align everything to what Microsoft or Microsoft Office does - but unless you consistantly opt for the sensational news, that position doesn't make very much sense.This has really nothing to do with aligning IS29500 with Microsoft Office; it has to do with aligning IS29500 with its scope.

Now, do note that we in WG4 cannot make decisions to alterating IS29500 - this is the prerogitive of the national bodies in SC34 or JTC1, so all we are doing is suggesting to the NBs that we think it is a good idea to reintroduce the two values.

Smile

Tags : . . .

Comments (9) -

Yoon-Kit Yong

Hi Jesper,

This was something which I realised during the BRM: we werent allowed to make modifications to the spec which 'broke' compatibility with the existing corpus of documents already in the wild.

I blogged about it here just after the BRM:

www.openmalaysiablog.com/.../geneva-day-five.html

which you, at that time, disputed my take here:

idippedut.dk/post/2008/03/02/BRM-aftermath.aspx

What I deduced from Alex Brown having to confer with the Ecma delegation that conformance wasn't broken before we could vote on a decision, was that modifications to the DIS at that time was very restricted. Major changes which improved the standard through elegant solutions WILL be voted down either on the convenors level, or via the voting bloc.

So the question is this: If ISO29500 from now and in the future, has to follow "The Scope" in making sure that existing documents will always be compliant, does this mean that all modifications to the spec should be additions and not redesigns?

i.e. ST_OnOff can possibly be [ on, off, true, false, 1, 0, aye, nay ] but never, ever, as a boolean [ true, false ] type?


yk

jlundstocholm

Hi Yoon Kit,

I still don't agree with your assertion that "we weren't allowed to make modifications to the spec which 'broke' compatibility with the existing corpus ...".

We were allowed to do just about everything apart from discussing the process of DIS29500.

It is true, however, that there was a wide feeling in the room that not making existing documents un-conformant was a good idea.

About redesign: you are essentially asking if we will ever take something away from OOXML, and that is a bit uncertain. Usually you won't take things out but you will eventually get to a point where you want to start all over again with something completely new.

Rick Jelliffe

It was obvious to me at the BRM that any changes that made actual OOXML files non-conforming against the transitional classes would not be sustainable, due to the scope, and I raised this frequently with people. In fact, I believe this was largely the shared sentiment at the BRM by the end, as can be seen for example from the decision on spreadsheet dates: allow the legacy and add better ones, then remove the legacy from the strict version. The strict/transitional approach provided buckets so that the needs of the past (legacy) and the future (convergence/less crappiness) were not in conflict.

So I was quite disappointed to discover that the boolean change had slipped through the BRM: I think it was a case where the ramifications of strict/transitional needed to be applied but weren't. (In fact, I would have expected ITTF and the editor to have raised a flag about it. SNAFU) The sooner these mistakes are fixed, the better.

But fixing 'transitional' T to reflect reality is only half the story: I think the main quality attributes T needs are accuracy and completeness--i.e. can a developer writing an import system figure out how to use the markup.

The other half of the story is 'strict' S: I think its main quality attributes are that it must be more positively convenient (so office-isms such as 1/20 point or 1/2 point attributes need to be removed, missing descriptions such as how lists actually work need to be added), simpler (VML and obsolete things removed, etc), and more supporting of plurality (to allow convergence with ODF by mixing parts, in the way that some ODF files now have embedded PDF in them to cope with full fidelity read-only requirements, to allow libraries of functions for spreadsheets..in particular an Open Formula library...and to remove arbitrary restrictions of invoked standards, such as ISO OpenType.)  

And I presume the deadline is to get as much of this work (which is nothing but taking up the work of the BRM) done before the release of Office 2010, which is maybe 9 months away, so that when Office starts to support ISO OOXML, the S OOXML would be recognizeable as the kind of thing that the BRM would have produced if it had more time. (I think I wrote at the time that maintenance at SC34 represented a kind of perpetual BRM. Developers will support the OOXML that Office uses; but they won't support ISO OOXML per se until it meets its basic quality attributes.)

Yoon-Kit Yong

Jesper,

> there was a wide feeling in the room that not making existing
> documents un-conformant was a good idea.

Which in essence meant that the modifications we did at the BRM was an addition of the solution, but never the removal of the "bad" (or not so optimal) designs.

If this was made clearer prior to the BRM, we would have had less confusion during our discussions on the floor. Im surprised that Doug had commented that Microsoft was open to break conformance. Perhaps we at the BRM overcompensated and was being too conservative in our changes?

Rick and Jesper,

I am hoping that Office 2010 would enforce a more 'Strict' flavour of ISO29500 than 'Transitional'. Have we got any commitment from the Microsoft team (Doug / Brian) on which conformance 'level' they will be moving towards? Will all old .doc files with graphics be immediately saved as VML in .docx rather than DrawingML, just because its old?

Something which wasn't addressed in the BRM, and maybe a SC34 item to discuss would be a deliberate timeline of retiring on an application level, the Transitional component of ISO29500. e.g. By 2010, all applications writing OOXML will only be in Strict conformance.

yk

hAl

Can anybody put this in a timeframe ?
When is this issue going to be resolved.

jlundstocholm

hAl,

I believe the COR1-set will be sent to ballot in SC34 within 6 weeks (sometime in August) and this will mean that if the ballot is approved, ITTF will publish the changes to IS29500 in January/February 2010.

Note: these are raw estimates by me

hAl

That would suggest that Office 2010 could include these fixes.

partsuk

"That would suggest that Office 2010 could include these fixes." - do we know whether this is now a given?

jlundstocholm

Hi partsuk,

"That would suggest that Office 2010 could include these fixes." - do we know whether this is now a given?

Well, I have tried to get Office 2010 to generate a document with the "bad" on/off-values, but so far unsuccessful.

I have written a bit more detailed about this in idippedut.dk/.../Moving-towards-OOXML3cS3e.aspx

Smile

Comments are closed