OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [OASIS Issue Tracker] Commented: (OFFICE-2694) ODF 1.2 draft 3breaks modularity

    [ http://tools.oasis-open.org/issues/browse/OFFICE-2694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19346#action_19346 ] 

Robert Weir  commented on OFFICE-2694:

OK.  I see what you are getting at, Dennis.  I think the context that is missing is that there has been a long side conversation among Patrick, MIchael, Mary and I what the OASIS requirements are in this situation.

We can either have:

A) Three separate specification, each with their own conformance clauses, scope, normative references, etc., to meet the requirements of an OASIS standard.  Each would be reviewed on its own, voted on a Committee Specification on its own, balloted as an OASIS Standard on its own, subjected to an OASIS Interop Demo on its own, submitted to JTC1 on its own, and maintained via separate errata and corrigenda.  Certainly, some of these procedures would occur concurrently, though they would be logically independent pieces and could be approved or disapproved independently.  

B) Have a single specification, but in multiple documents, and take that single specification through the approval processes in OASIS and ISO.  For this to occur we need to have a single formal document that has the consolidated TOC, conformance clauses, etc.  I am not very happy with they way this "part 0" looks.  If there is a way to make it look better and still meet the OASIS requirements, then I'm all ears.

What there isn't is something in between, where we have a single OASIS ballot with three specifications each with their own conformance clauses.

As for what "ECMA and JTC1 manage without difficulty", in that case they are separate standards. ISO/IEC 29500-1. is OOXML Part 1, for example.  Each part is its own standard and can be corrected or amended independently.  So that is more like option A) above.  But my perception is that this has been far from "without difficultly" for SC34.  They have found that the physical structure of their standards does not perfectly align with their schemas and their conformance definitions.  So changing one "feature" can involve making changes to more than one of the OOXML standards.  We've seen something like 4 corrigenda documents and 3 amendments come through, with more on the way.  This is something I'd like to avoid.  The process overhead of maintaining these as distinct standards has occupied the attention of their committee to the extent that they have not added a single substantive feature to the standard in the 2 years since it was approved.

Modularization is important, but I think it is a "measure twice, cut once" kind of thing.  You really need to have it done perfectly.

> ODF 1.2 draft 3 breaks modularity
> ---------------------------------
>                 Key: OFFICE-2694
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-2694
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Bug
>          Components: Conformance, General
>    Affects Versions: ODF 1.2 Part 3 CD 2, ODF 1.2 Part 1 CD 5, ODF 1.2 Part 2 CD 3
>         Environment: This issue applies to the restructured parts 1-2-3 and the overview that are balloted for approval as a Committee Draft(s) for Public Review: OpenDocument-v1.2-draft3.odt, OpenDocument-v1.2-part1-cd04-rev08.odt, OpenDocument-v1.2-part2-cd02-rev08.odt, and OpenDocument-v1.2-part3-cd01-rev07.odt.
>            Reporter: Dennis Hamilton
>            Priority: Blocker
>             Fix For: ODF 1.2
> 1. This new packaging breaks the modularity by which part2 and part3 are independently usable and relatively self-contained.  
>     1.1 The removal of conformance sections from all parts, with the only conformance section being in the OpenDocument-v1.2-draft3.odt causes these parts to be inextricably intertwined.  This strikes me as a question of substance that requires discussion.
>     1.2 This organization also creates unnecessary duplication and burdens readers with the need to consult multiple documents for no useful purpose.
>     1.3 The additional complexity of maintenance of the specifications, potential errata and defect-reconciliation efforts, and the prospect of inconsistency between the parts seems unjustifiable.  (There are already inconsistencies between the new 1.2-draft3 and provisions referenced in the other parts of the specification.)
>  2. It also seems excessive that OpenDocument-v1.2-draft3.odt consists of 
>   * 93 pages of front matter, including duplication of the tables of contents of parts 1-3, 
>    * 3 pages of back matter, and 
>    * only three pages having modest narrative content and creating a list of conformance clauses that makes it indispensible to the other parts.
>  3. Finally, I think this approach is an unwarranted imposition on the time and efforts of those who we wish to embrace this specification, invest in its review, and engage in implementation, testing, and verification of products that support OpenDocument.
> [Note: I am concerned that attempting to remedy this as part of a re-issue in a 15-day secondary public review would be too dificult.  After examining the material and the new sections 2 of Parts 1-3, I am satisfied that correction by elimination of v1.2-draft3 is workable.]

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]