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

 


Help: OASIS Mailing Lists Help | MarkMail Help

plcs-tog message

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


Subject: RE: PLCS TC - the next edition ????


I attach for your information the relevant extract from the SC4 Handbook on Change Management, which highlights the relevant options.
 
Either Amendment or Revision (to get a new edition) require the normal ballot cycle.  TCs can be issued by the Working Groups.  Minor revisions, resulting in a complete new document, require an FDIS ballot.
 
 
In response to Rob's questions:
 

This raise several questions about the TC process.

1)       How long does it take to produce a TC?

HGM> drafting time plus a couple of weeks to approve and process in ISO

2)       What do we need to produce? A complete new AP package?

HGM>  Not for a TC - you might wish to generate a monor revision if htere are many changes

3)       Does it require a ballot process?

HGM> Not for a TC - just agreement in the WG

4)       How many can we produce? I.e should we wait until we have a number of issues addressed then release the TC, or release a TC everytime we address an issue?

HGM Wait- there is normally a maximum of two TC before you issue a new edition - sometimes can stretch to three.

5)       Can we make major modifications in the TC? E.g. bring the Risk module, address the config management of tasks, or should we just address clear errors like missing select extensions

HGM>  This sounds like a new edition - we can hardly call it a minor revision.. Just fix errors in a TC.

 


From: Rob Bodington [mailto:rob.bodington@eurostep.com]
Sent: 19 June 2006 14:48
To: plcs-tog@lists.oasis-open.org; plcs-dex@lists.oasis-open.org; Mason, Howard (UK)
Subject: PLCS TC - the next edition ????

*** WARNING ***

This mail has originated outside your organization,
either from an external partner or the Global Internet.
Keep this in mind if you answer this message.

Hi

I was wondering what the process for producing a Technical Corrieganda PLCS would be.

 

As we are developing the capabilities, we are finding some selects that should have been extended. In a couple of cases, this is preventing us from completing the capabilities, or forcing us to represent something in a less optimal way.

 

I was thinking that we need a formal process for dealing with modifications to the AP that takes into account the short term requirements to make fixes to the AP for implementations and the requirement to ensure that these fixes are rolled back into the ISO document.

 

My proposal is that we:

1) Record the issues against AP239 in a single issue log in dexlib – i.e. dexlib/docs/issues/ap239_issues.xml

 

2) Raise the issue as SEDS so that they are registered against ISO 10303-239, recoding the seds number in the issue log

 

3) Copy the EXPRESS models for the AP to DEXLIb. Have two files. One a concatenation of all module ARMs, and the other being the long form derived from the ARMs. Fix the EXPRESS according to the issue.

 

4) Modify the capabilities to use the modified EXPRESS and include a note in the capability referring to the issue and SEDs and to say that it deviates from the standard, but that the issue has been raised against the standard.

 

5) At some point in time, raise a TC against PLCS.

 

This raise several questions about the TC process.

1)       How long does it take to produce a TC?

2)       What do we need to produce? A complete new AP package?

3)       Does it require a ballot process?

4)       How many can we produce? I.e should we wait until we have a number of issues addressed then release the TC, or release a TC everytime we address an issue?

5)       Can we make major modifications in the TC? E.g. bring the Risk module, address the config management of tasks, or should we just address clear errors like missing select extensions

 

I realise that this opens a potential Pandora’s box of changes that we might be tempted to make, but given where we are with PLCS, I think that we should limit the TC to fixing errors.

 

What does everyone think?

 

In the mean time, I will create:

1)       The issue log at: dexlib/docs/issues/ap239_issues.xml

2)       The EXPRESS files:
dexlib/docs/ap239/ap239_arm_lf.exp dexlib/docs/ap239/ap239_arm_lf.xml (derived from ap239_arm_lf.exp)
dexlib/docs/ap239/ap239_arm_sf.exp dexlib/docs/ap239/ap239_arm_sf.xml (derived from ap239_arm_lf.exp)

 

Regards
Rob

-------------------------------------------   
Rob Bodington
Eurostep Limited
Web Page:
http://www.eurostep.com http://www.share-a-space.com
Email: Rob.Bodington@eurostep.com
Phone: +44 (0)1452 810 960
Mobile: +44 (0)7796 176 401

 

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
Title: SC4 Organization Handbook, Clause 3 - Maintenance

3. Maintenance

3.1 Initiation of changes

The ISO Directives (IDP1, 2.9) call for a systematic review of standards after five years. Systematic reviews may lead to withdrawal or confirmation of a standard, or directly to an agreed new work item for a revision, given sufficient support for the changes.

In the absence of a conclusive vote to approve the launch of a revision, member bodies may submit a NWI proposal for an amendment or revision which addresses the comments raised during the systematic review. A draft document may be submitted with the proposal for a combined NWI/CD ballot. The NWI should be submitted to SC4 Change Management within six months of the closure of the review. If the NWI ballot is successful, the standard will be revised. In the absence of an NWI proposal within six months, or if there is insufficient support for such an NWI, the document will be confirmed.

Systematic reviews of Technical Specifications and Publicly Available Specifications must be undertaken after three years. The first systematic review of a Technical Specification may lead to a proposal to withdraw, confirm or revise the specification, or to progress the specification to Draft International Standard. The second review cannot reconfirm the TS. If there is inadequate support in the review to approve the direct progress to DIS ballot, a CD ballot may be held to confirm the proposed DIS.

In addition. SC4 has established a Standard Enhancement and Discrepancy System (SEDS) to manage the identification of the need for modifications and corrections and to track the progress of these identified needs until they become part of the appropriate International Standard or Specification through the ISO publication procedures.

SC4 has assigned responsibility for identifying the need for modifications and corrections to conveners of the SC4 working groups (see clause 7.7 of this Handbook) and the Change Management Committee (see clause 6.2 of this Handbook). The working group convener is responsible for recommending to the SC4 secretariat preparation of a technical corrigendum or preliminary work item or new work item proposal to incorporate needed changes in the form of an amendment or revision. These recommendations (see clause 7.7.1) shall be based on an assessment of the accumulated needs from:

The convener may also consider input from other sources in the development of the recommendation.

Changes may also be proposed as a new work item as provided for in IDP1, 2.3.1.

The Change Management Committee is responsible for reviewing preliminary work items and new work items that propose changes to existing International Standards before submission to SC4 national bodies for approval (see clause 6.2.2).

3.2 Publication of changes

The ISO procedures for modifying an International Standard are set forth in clauses 2.3 and 2.10 of the ISO Directives, Part 1. The Directives provide three forms of modifications:

SC4 established a Standard Enhancement and Discrepancy System (SEDS) to manage the identification of the need for modifications and corrections and to track the progress of these identified needs until they become part of the appropriate International Standard through the ISO publication procedures. SC4 has assigned responsibility for identifying needs to conveners of the SC4 working groups (see clause 7.7 of this Handbook) and the Change Management Committee (see clause 6.2 of this Handbook).

3.2.1 Technical corrigendum

A technical corrigendum, as described in IDP1, 2.10.2, "...is issued to correct a technical error or ambiguity in an International Standard, inadvertently introduced either in drafting or in printing and which could lead to incorrect or unsafe application of the International Standard...." The SC4 secretariat is responsible for submitting a technical corrigendum to the ISO CEO after its preparation by the appropriate SC4 working group.

3.2.2 Amendment

An amendment, as described in IDP1, 2.10.3, "...alters and/or adds to previously agreed technical provisions in an existing International Standard."

The procedure for authorizing, developing and approving an amendment shall be as described in clauses 2.3 through 2.7 of this Handbook.

3.2.3 Revision

A revision to an International Standard results in the publication of a new edition of the standard. Revisions may take one of two forms.

3.2.3.1 Revision

A revision is developed when the extent and scope of the changes being made make it impractical to publish the changes in the form of an amendment.

The procedure for authorizing, developing and approving a revision shall be as described in clauses 2.3 through 2.7 of this Handbook.

3.2.3.2 Minor revision

A minor revision is developed when there are no fundamental changes to the existing International Standard and when a)the use of a technical corrigendum is not justified as described in IDP1, 2.10.1 or b)the cost and time for a full revision as described in clause 3.1.3.1 of this Handbook is not justified.

The procedure for authorizing, developing and approving a minor revision is not described in the ISO Directives. The ISO technical officer for SC4 describes the process as: a) Develop a completely new document, b) Forward the document to ISO with a certification by the SC4 Secretary that there are not fundamental changes and request publication as a minor revision, c) ISO will ballot as an FDIS and upon a successful ballot publish as a new edition of the International Standard.

Within SC4, the proposer shall seek the advice of the Change Management Committee. They will provide to the committee: a)An explanation of the need for the minor revision as documented in SEDS reports, b)an explanation of the expected changes to the standard and why the resulting documents will not make a fundamental change to the existing international standard and c)the schedule and resources for producing the required document.

Upon acceptance of the information provided, the Change Management Committee will advise the secretary to draft a resolution for SC4 to authorize the commencement of work on the minor revision.

Approval by SC4 shall require the same level of approval as the current level of approval for an FDIS ballot.

When the document is completed, complying with SC4 procedures and checklists, the secretary will forward the document to ISO CS for ballot circulation as a minor revision.

3.3 Standard Enhancement and Discrepancy System (SEDS)

To provide an orderly process for submitting and resolving problems encountered in developing, implementing and the use of the SC4 standards and standing documents,  and to gather requirements and proposals for enhancements to future editions, the Standard Enhancement and Discrepancy System (SEDS) tracking system has been implemented by the SC4 secretariat. Figure 3 details the SEDS submission and review process.

Figure 3 - SEDS Submission and Review Process

3.3.1 Submission of reports

Reports of problems or errors in the SC4 International Standards or standing documents shall be submitted using the form found in annex G.1.5. This same form shall be used to submit suggestions and requests for enhancements or corrections to SC4 International Standards and standing documents. It is expected that users, implementors and standards developers will be among the population of those submitting reports. There are no requirements or qualifications that are placed on the submitter of the report beyond completing the information required on the SEDS form. SC4 does not want to inhibit the submission of reports. A submitter, however, should expect to be available for:

Any issues submitted during the ISO ballot process that are classified as "deferred" during the ballot resolution process are transferred into the SEDS process by the responsible project leader and/or convener. This procedure ensures that all relevant issues are considered when amendments or new editions are being proposed or developed. All issues transferred from ballots are assigned priority 0 or priority 1, as defined in 3.3.3.2 below.

3.3.2 Processing of the reports

 SEDS reports shall be submitted in electronic form to the SC4 secretariat.

 The SC4 secretariat shall:

 The responsible convener shall:

 The SC4 secretariat shall:

3.3.3 Classification and prioritization of reports

The classification system for SEDS reports has been established to categorize the needed resolution of the issues raised by the report. In addition a system of priorities is established to convey the urgency for incorporating the reports in an International Standard or standing document.

 3.3.3.1 Classification

 Each SEDS report shall be assigned to one of the classes below. The submitter may provide a classification, but the responsible convener ultimately determines the classification.

Class T (technical corrigendum)

The report identifies a fault that will result in unsafe or incorrect application of the standard. A correction shall be immediately developed and technical corrigendum shall be prepared.

Class I (information)

The report identifies an omission, ambiguity, unclear text or an inadequate definition.

Clarifying information shall be developed and provided in the completed report. This information should be useful to those attempting to use the standard and encountering a similar difficulty, but need not take the form of a proposed revision to the standard.

A comprehensive response shall be developed when an amendment or revision to the standard or standing document is prepared. During this preparation, the resolution of the report might be combined with other SEDS reports.

Class R (requirement)

The report identifies a new requirement. Discussion of possible means of satisfying the requirement shall be initiated, but a final specification need not be developed. The provision of specifications to meet the requirement shall be provided in the next amendment or revision, when it may be combined with other SEDS reports.

Class E (editorial)

The report identifies a minor editorial change having no consequence in the application of the International Standard or standing document. A change shall be made in the next amendment or revision.

3.3.3.2 Priority

For each SEDS report, a priority shall be assigned to indicate the urgency of issuing a technical corrigendum or incorporating the results of the report resolution into an International Standard or revised Standing Document. The values to be assigned are:

0 Incorporate SEDS resolution whenever a revision or amendment is developed;

1 Low priority--revision or amendment need not be considered unless a significant number of these have been accumulated;

2 Medium priority--the need for an amendment, technical corrigendum or revision should be discussed by the working group;

3 High priority--an amendment, technical corrigendum or revision is urgently required.

3.4 Incorporation of SEDS

 The SC4 secretariat tracks the incorporation of SEDS issues on a per-part basis. Often a single SEDS report will affect several parts. When a SEDS report is closed and incorporated into a technical corrigendum, amendment or revision, the cover for that document shall enumerate the SEDS reports incorporated by that document.



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