From owner-incits-v1@incits-v1.org Wed Oct 24 10:59:19 2007 MIME-Version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_vRwJcWl1AGIA5pfOR/16ag)" Date: Wed, 24 Oct 2007 13:56:06 -0400 From: "Mason, James David (MXM)" Subject: RE: INCITS-V1: AFNOR proposal for revisable office document formats In-reply-to: Sender: owner-incits-v1@incits-v1.org To: incits-v1@incits-v1.org Reply-to: incits-v1@incits-v1.org X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Thread-topic: INCITS-V1: AFNOR proposal for revisable office document formats Thread-index: AcgWWEqrm9n3IV1dSBqVfgWC8PCMkwACyFsA X-PMX-Version: 5.2.0.264296 X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 24 Oct 2007 17:56:20.0197 (UTC) FILETIME=[2EC20950:01C81667] This is a multi-part message in MIME format. --Boundary_(ID_vRwJcWl1AGIA5pfOR/16ag) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT SC34 has done several Type 2 Technical Reports (e.g., ISO TR 9541-11, the documentation for the XML publishing application used at ISO-CS). We have not done a Technical Specification. A Technical Specification, as explained in earlier versions of the JTC1 Directives, was a document that the responsible committee agreed was a potential standard but that for a number of reasons (e.g., immaturity, condition of the text, disagreement on options) was not yet ready for final adoption. In the 2001 edition of the Directives, Technical Reports, Technical Specifications, and Publicly Available Specifications were all discussed in Clause 3. (PAS is how ODF came to us.) A TR was descriptive only; it could not contain normative specifications. A TS and a PAS, like an IS, could contain normative specifications. It is clear that a TR is not intended to become a standard but a TS and a PAS are expected to become progress to IS as soon as they can be processed. I would say that what I find in the older edition of the directives as a reason for publishing something as a TS comes pretty close to the state we may be in if the BRM next year is unable to come to a full resolution of the issues raised on the ballot. However, the current version of the Directives (SC34 N856 Rev) does not mention TS as a formal document type. They use "technical specification" to describe the contents of an IS or PAS. (Preparation of IS is Clause 12, Fast Track is Clause 13, PAS transposition is Clause 14.) Jim Mason ________________________________ From: owner-incits-v1@incits-v1.org [mailto:owner-incits-v1@incits-v1.org] On Behalf Of robert_weir@us.ibm.com Sent: Wednesday, October 24, 2007 12:07 PM To: incits-v1@incits-v1.org Subject: Re: INCITS-V1: AFNOR proposal for revisable office document formats 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: 1. Split ECMA 376 into two parts, a core ("essential") part and a "legacy" extensions part containing items like VML. 2. Approve both as a two-part Technical Specification 3. 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_vRwJcWl1AGIA5pfOR/16ag) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
SC34 has done several Type 2 Technical Reports (e.g., ISO TR 9541-11, the documentation for the XML publishing application used at ISO-CS).
 
We have not done a Technical Specification. A Technical Specification, as explained in earlier versions of the JTC1 Directives, was a document that the responsible committee agreed was a potential standard but that for a number of reasons (e.g., immaturity, condition of the text, disagreement on options) was not yet ready for final adoption.
 
In the 2001 edition of the Directives, Technical Reports, Technical Specifications, and Publicly Available Specifications were all discussed in Clause 3. (PAS is how ODF came to us.) A TR was descriptive only; it could not contain normative specifications. A TS and a PAS, like an IS, could contain normative specifications.
 
It is clear that a TR is not intended to become a standard but a TS and a PAS are expected to become progress to IS as soon as they can be processed.
 
I would say that what I find in the older edition of the directives as a reason for publishing something as a TS comes pretty close to the state we may be in if the BRM next year is unable to come to a full resolution of the issues raised on the ballot.
 
However, the current version of the Directives (SC34 N856 Rev) does not mention TS as a formal document type. They use "technical specification" to describe the contents of an IS or PAS. (Preparation of IS is Clause 12, Fast Track is Clause 13, PAS transposition is Clause 14.)
 
Jim Mason


From: owner-incits-v1@incits-v1.org [mailto:owner-incits-v1@incits-v1.org] On Behalf Of robert_weir@us.ibm.com
Sent: Wednesday, October 24, 2007 12:07 PM
To: incits-v1@incits-v1.org
Subject: Re: INCITS-V1: AFNOR proposal for revisable office document formats


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:
  1. Split ECMA 376 into two parts, a core ("essential") part and a "legacy" extensions part containing items like VML.
  2. Approve both as a two-part Technical Specification
  3. 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_vRwJcWl1AGIA5pfOR/16ag)--