Inverse attributes in EXPRESS-G?

[David Price]

Phil,

I think you should write a ballot comment and put the proposed solution in
it.  The final decision will be made at the Amendment DIS ballot resolution
workshop.  I checked and the DIS ballot looks like it started in April.
That means it ends either in September or October - I don't know if it's a 5
or 6 month ballot.

WG11/EXPRESS folks - based on a Sept/Oct DIS ballot closure, is the October
Japan ISO meeting the best time to resolve the ballot comments?  The next
chance is Feb 2002 in the US. We need to know by August 20 as that's the
deadline for meeting requests for Japan.

Also, I think at the last ISO meeting WG11 agreed to move the exploder to
wg11 at steptools.com  because smiling.net stopped working. So, I don't think
everyone has heard about this.

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


-----Original Message-----
From: wg11 at smiling.net [mailto:wg11 at smiling.net]
Sent: 03 August 2001 11:25
To: david.price at eurostep.com
Subject: RE: Inverse attributes in EXPRESS-G?


from: "Phil Spiby" <Phil.Spiby at Eurostep.com>
Folks,

Since I have had no responses to this I guess everyone is happy with my
assessment of the problem and the proposal.

On reflection, I think it may be useful to have more information available
to the EXPRESS-G reader, such as the entity in which the explicit attribute
is declared in addition to the explicit attribute name. To support this my
proposal would be changed to have
(entity.attribute) instead of (attribute)
displayed to define this information.

Phil

> -----Original Message-----
> From: Phil Spiby [mailto:Phil.Spiby at Eurostep.com]
> Sent: Monday, July 30, 2001 12:09 PM
> To: wg11 at smiling.net
> Subject: Inverse attributes in EXPRESS-G?
>
>
> Folks,
>
> Having just reviewed some of the STEP modules, I was surprised to
> see a new form of EXPRESS-G being used. This new form of
> EXPRESS-G adds the capability to document inverse attributes,
> which are not just the simple inverses covered by adding the
> (INV) label to an explicit attribute. For example in ISO/CD TS
> 10303-1017 Product Identification ARM EXPRESS-G we have the
> following EXPRESS:
>
> SCHEMA Product_identification_arm;
>
> USE FROM Person_organisation_assignment_arm;
>
> TYPE product_organisation_or_person_in_organisation_item = SELECT
>   BASED_ON organisation_or_person_in_organisation_item WITH
>   (Product);
> END_TYPE;
>
> ENTITY Product;
> ...
> INVERSE
>   identifier : Organisation_or_person_in_organisation_assignment
> FOR items;
> ...
> END_ENTITY;
>
> END_SCHEMA;
>
> SCHEMA Person_organisation_assignment_arm;
>
> TYPE organisation_or_person_in_organisation_item = EXTENSIBLE SELECT
>   ();
> END_TYPE;
>
> ENTITY Organisation_or_person_in_organisation_assignment;
> ...
>   items : SET [1:?] OF organisation_or_person_in_organisation_item;
> END_ENTITY;
>
> END_SCHEMA;
>
> This is valid EXPRESS, or appears to be by visual parsing!
>
> The problem comes in the EXPRESS-G diagram (arm.gif attached),
> where the inverse attribute identifier of product, is represented
> as an attribute line going from product, to the used
> Organisation_or_person_in_organisation_assignment, this line has
> no explicit attribute name, and has (INV) identifier marked on
> it. To my understanding of EXPRESS-G, this line signifies that
> there is an un-named attribute in product, and an inverse
> attribute called identifier in the use of
> Organisation_or_person_in_organisation_assignment.
>
> Therefore there is a problem here. I do not blame the authors of
> this particular model (this is done through out the modules, and
> I selected this as an example due to its small size). There is no
> standard way, that I know of, for showing this type of inverse
> attribute in EXPRESS-G. These inverse attributes are important,
> especially in the modules where use of extended selects etc to
> enable extensible models requires such inverse attributes.
>
> Proposal:
> I suggest that we introduce a new graphical construct, to support
> the display of such inverse attributes. This inverse attribute
> glyph should be added to the EXPRESS DAM in it's DIS ballot
> cycle. The glyph itself should be structured as follows:
>
> An inverse attribute is denoted by a normal line linking the
> entity in which the inverse attribute is defined and entity (or
> object_proxy, reference or use representing the entity) which
> represents the target of the inverse attribute. The target of an
> inverse attribute may be the entity declaring the explicit
> attribute, for which this is an inverse, or a subtype of that entity.
> The end of the line connected to the entity which contains the
> inverse attribute is signified by an open circle.
> The end of the line connected to the target entity has no end style.
> The name of the original explicit attribute is placed adjacent to
> the line within parenthesis.
> The characters INV in parenthesis, i.e., (INV) before the name of
> the inverse attribute, which is placed adjacent to the line.
> If the inverse attribute is constrained either by a where rule or a
> unique rule the attribute name is preceded by a superscripted asterisk *.
> If the attribute is defined by an aggregation datatype then the
> aggregate is denoted as given in D.5.2, following the attribute name.
> If the inverse attribute is a redeclared attribute, then it shall
> include the characters RT in parenthesis, i.e., (RT) before the
> (INV) characters.
>
> This would result in a change to the example, as given in arm_new.gif.
>
>
> The rationale, behind this proposal is as follows:
> 1. It keeps the original explicit attribute style, so inverse
> attributes marked on explicit attribute lines can be read in the
> same way as inverse attributes marked in the new way.
>
> 2. We need information about what the original explicit attribute
> was called, otherwise we have no graphical indication of what
> this is an inverse of.
>
> 3. By placing parenthesis around the explicit attribute name we
> clearly signify that this is not an actual explicit attribute. (I
> could accept delimiters other than parenthesis if people object
> to their use!).
>
> 4. By placing this capability in the proposed DAM, we give the
> modules developers (I am one now as well!) the tools to better
> develop/document their models.
>
> Comments?
>
> Phil
>
> -----------------------------------------------------------
> Dr. Phil Spiby               Tel: +44 1623 522940
> Eurostep Limited             Fax: +44 1623 522941
> 73 Columbia Avenue           Mobile: +44 7785 990352
> Sutton-in-Ashfield           Email:Phil.Spiby at Eurostep.com
> Nottinghamshire
> NG17 2GZ
> United Kingdom