From owner-incits-v1@incits-v1.org Wed Oct 24 09:08:20 2007
MIME-Version: 1.0
Content-type: multipart/alternative;
boundary="Boundary_(ID_DXB9Bco/n+HasuOBVSK11w)"
Date: Wed, 24 Oct 2007 12:06:56 -0400
From: robert_weir@us.ibm.com
Subject: Re: INCITS-V1: AFNOR proposal for revisable office document formats
In-reply-to: <200710232349.l9NNn32g708067@jurassic-x4600.sfbay.sun.com>
Sender: owner-incits-v1@incits-v1.org
To: incits-v1@incits-v1.org
Reply-to: incits-v1@incits-v1.org
X-MIMETrack: Serialize by Router on WTFMAIL03/WTF/M/Lotus(Build
V704_10142007|October 14, 2007) at 10/24/2007 12:06:57 PM,
Serialize complete at 10/24/2007 12:06:57 PM
X-PMX-Version: 5.2.0.264296
X-Brightmail-Tracker: AAAAAA==
X-Brightmail-Tracker: AAAAAA==
This is a multipart message in MIME format.
--Boundary_(ID_DXB9Bco/n+HasuOBVSK11w)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
If you have access to AFNOR's DIS 29500 ballot comments you can read a
fuller account of their proposal as J1N8726-03.doc. It seems to boil down
to:
Split ECMA 376 into two parts, a core ("essential") part and a "legacy"
extensions part containing items like VML.
Approve both as a two-part Technical Specification
Converge ODF and OOXML-Core
I'd note that some of these ideas were echoed by other NB's. For example,
I believe V1 also recommended a formal multi-part submission (3rd comment
on page 3 of our comments).
Also, Standards New Zealand recommended: "The DIS standard be considered
by JTC 1 committee for publication as a Type 2 Technical report" and "Seek
to harmonize with the existing ODF standard to reduce the: cost of
interoperability, cost of having two Standards, cost of
support/maintenance."
(Maybe someone can tell us what the formal difference is between a
"Technical Specification", a "Type 2 Technical Report." Do either of them
even exist in JTC1?)
IMHO, some sort of split is warranted for a standard of this length and
complexity. We've already seen that at its present length it is
impractical to process -- too much to swallow at once. But does it more
naturally split by functional area (spreadsheet versus word processor
versus presentation) or by core versus legacy? I can see arguments either
way.
As for convergence, I'd look at DIS 29500 Part 5, and the extensibility
elements there. If legacy extensions in DIS 29500 were expressed using
that mechanism, and if ODF adopted this same extensibility mechanism, then
I think we would have any easier time of it.
On the other hand, the difficulty with convergence appears to be more
political than technical. We can probably come up with several different
good technical approaches to convergence without stumbling on a single
workable political solution.
-Rob
owner-incits-v1@incits-v1.org wrote on 10/23/2007 07:49:03 PM:
> AFNOR, the French National Body, has made an interesting proposal
> for the progress of both OOXML and ODF:
>
> http://www.infotechfrance.com/cgi-local/affichage_signets.pl?
> UNI_ID=8&RUB_ID=53&SIG_ID=4304&actu=1
>
> This plan strikes me as quite sensible. What do other members of
> V1 think?
>
> Jon
___________________________
Rob Weir
Software Architect
Workplace, Portal and Collaboration Software
IBM Software Group
email: robert_weir@us.ibm.com
phone: 1-978-399-7122
blog: http://www.robweir.com/blog/
--Boundary_(ID_DXB9Bco/n+HasuOBVSK11w)
Content-type: text/html; charset=US-ASCII
Content-transfer-encoding: 7BIT
If you have access to AFNOR's DIS 29500
ballot comments you can read a fuller account of their proposal as J1N8726-03.doc.
It seems to boil down to: