Comments on Impact of STEP Modularization

[David Price]

Pascal,

You raise some good concerns. However, some implementors are becoming more
EXPRESS-aware and can deal with short form schemas. The modular approach,
SDAI, Part 21 extensions, Part 28 can now deal with data from different
schemas and the relationship between them.  I don't think anyone disagrees
that long form schemas for implementable modules (e.g. those that are the
ARM/Mapping/schema for an AP) will be available for implementors. The
question is where and how will they be available and will their being "more
standard than the short form" continue to be true. The AP/AM guidelines are
out for ballot so now is the time when these final details should be worked
out.

The WG10 project took a leap and proposed that the normative schema is the
short form and so that's all that's required to be published in every AM.
Sometimes you have to push the envelope to understand how far people have
come in their understanding of this type of issue. It's now up to SC4 to
decide if the WG10 proposal goes too far and exactly how to bring it more in
line with what's acceptable if it did go to far.

In either case, it's quite easy to handle this issue!  FYI, Allison, Jochen,
Anna W and I are working on the EXPRESS 2 to long form white paper for
SHTOLO2 as we speak.

Just to throw another idea into the pot, if the requirement for the long
form came from implementors/users needing an easy way to see all the EXPRESS
concepts they have to understand to implement an AP schema, then a long form
is not the only solution. For Part 25 EXPRESS/UML mapping, we decided not to
create a single UML Model (i.e. long form) but to leave the contructs in
their separate models deleting the ones that are not visible to the AP
schema. That leaves the structure of the network of schemas in place but
makes it easy to see what you have to implement. We could also modify that
idea by only keeping the schema structure intact up to a point...perhaps
only "implementable" AMs schemas would be kept. I don't know if that's what
we'd want to do with APs but these are alternative way of looking at things
that could work better in enabling reusable code development, etc.

Thanks,
David

-----Original Message-----
From: pascalhuau at compuserve.com [mailto:pascalhuau at compuserve.com]
Sent: 02 August 2001 13:28
To: pfAeroFW, ISOWG12; David Price
Cc: WG12; WG10
Subject: Re: Comments on Impact of STEP Modularization


Dear Greg and Dave,


You wrote in a previous mail:
> >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.
>

I am rather surprised by the fact that the question of finding or not an AIM
schema in a AP using modules is still to be discussed.
Are you really saying that you are promoting the design of application
modules without knowing or having decided how the APs that will use them,
should be built?

>From a more technical point of view, I would say that as long as we do not
have a unique, standard, implementable and implemented algorithm enabling to
merge AMs in a common
Express schema, the presence of an AIM schema in an AP using modules should
be mandatory.
A good indicator of the difficulty to switch from several Express schemas to
a big one can be obtained from the experience with translations
 from short to long form schemas: most of time, the generation was partly
automated but also completed by
hand (because of the difficulty to remove unwanted subtypes, to adapt select
types, ...).
In addition, if there is an AIM schema, you have one reference. Whereas with
several schemas, some of them with one or more TCs, it would be much less
obvious  to be sure that two implementors have really worked on the same
basis.
Then, the industrial companies that implement STEP APs presently are, most
of times, using toolkits that can only process only one Express schema,
associated in many PDM cases, with one ExpressX schema.
Therefore, requiring an AIM schema, at least for first APs using modules,
seems to me much safer and easier for implementors.


Regards,
Pascal Huau
Association GOSET
107,111 avenue Clemenceau
92000 Nanterre
France