Comments on Impact of STEP Modularization on the SC4 Common R esources White Paper

[pfAeroFW, ISOWG12]

Some questions - possibly a misunderstanding on how this is to work - see
GAP>

-----Original Message-----
From: David Price [mailto:david.price at eurostep.com]
Sent: Wednesday, August 01, 2001 5:35 AM
To: pfAeroFW ISOWG12; 'Exploder WG12 (ProSTEP)'; WG10 at steptools.com
Subject: RE: Comments on Impact of STEP Modularization on the SC4 Common
Resources White Paper

Greg,

A couple of responses to your issues - thanks for the review!

>2) Clause 2 - 6th paragraph - Disagree on statement that AP made up of AMs
>do not need a long form.  Several reasons: a) If an AP does not have a long
>form, then a user who attempts to implement the AP will not know what the
>EXPRESS constructs are for the AP.  b) An AM may be published with several
>corrections, the AP needs to know version of the EXPRESS is valid for the
>standard. c) The Extensible Selects need to be completed by the AP.  d) The
>proliferation of AMs would result in several new/modified Extensible
Selects
>- how does the AP reconcile the different Extensible Selects.

Agree that the long form question remains an open issue to be worked.
Disagree on completion of EXPRESS selects in AP, there really isn't an
AP schema. See next issue.

GAP> A possible solution is that the AP AIM EXPRESS is Normative as an
Annex. On the disagree point - Should I assume that the AM that contains the
majority of the AP content (for discussion purposes let's call this the AM
AP) will complete all of the Extensible Selects for the AP.  This completion
would also resolve any duplication of selects into a single Extensible
Select (for example if applied_approval_assignment were used in several AMs,
the AM AP would resolve - and complete - the applied_approval_assignment?)?

>3) Clause 2 - 6th paragraph - Disagree on statement that SC4 is going to be
>required to maintain a repository of AM ARM EXPRESS schemas.  The AP will
>need to put these together in the AP context, the AM AIM EXPRESS will be a
>fall-out of this process.  The AM AIM EXPRESS will need to unique to work
>across all contexts.  THE AM ARM EXPRESS will NOT need to unique to work
>across all contexts.

In the new architecture, there is no "AP AIM EXPRESS".  The AP simply points
to an AM that contains the EXPRESS. An AM ARM may be reused in a larger
context (e.g. AP209 took AP203 ARM and AIM as a basis and then extended it).
The
idea is to make an AM that's the ARM/MIM for an AP reusable by an AM for a
larger
AP.
Separation of business specific rules into only the AM that equates to an AP
will further enable this reusable.

GAP> See prior GAP> for AP AIM EXPRESS.  On the second point, would it be a
good idea to leave the global rules out of the AM AP?  Rationale: Several of
the APs have additional concepts in the APs that require
modification/changes to Global Rules if they were to be used in another AP
context.  For example, in AP1 a Global Rule that does not allow the
population of ENTITY X.  ENTITY X is used in AP2 for a new concept.  AP2
would be required to construct another entire AM AP because of the need to
not have the Global Rule on ENTITY X.   AP2 may have a Global Rule that only
allows ENTITY X in some specific populations.

>4) Clause 3 - Disagree - AIC should still be allowed to be developed.

There reason is that there's no way to use an AIC in a modularized AP.

GAP> Why?  Does EXPRESS disallow this?

GAP> Hope the new home site is well.

Cheers,
David

Phone: +44 (0)207 697 9790
Mobile +44 (0)778 856 1308
Fax: +44 (0)207 697 0879
Eurostep Limited
47A Huntingdon Street
London, N1 1BP, UK