Group qualified inverse attributes?

[Pascal Huau]

Phil,

For the moment, because of the previous constraint, the attribute names
after FOR in Inverse statements are either a name of an own attribute of the
referencing entity or the name of an inherited attribute of that entity.
As long as this latter syntax remains allowed (for upward compatibility
reasons), I have no problem with the proposal.

I propose that kind of syntax:

> INVERSE
>   inv_att : SET[1:?] OF sub FOR sub\sup1.att;
>

Regards,
Pascal Huau
Association GOSET
107,111 avenue Georges Clemenceau
92000 Nanterre
FRANCE
----- Message d'origine -----
De : "Phil Spiby" <esukpc02 at nildram.co.uk>
À : <wg11 at steptools.com>
Envoyé : lundi 15 juillet 2002 15:26
Objet : Group qualified inverse attributes?


> Expressarios,
>
> The ballot comment NSF2 from Norway (given below) was accepted.
>
> NSF2: In TC2 a restriction has been introduced concerning valid types
> for INVERSE: "The name of the explicit attribute in the entity defining
> the direct relationship shall be unique within the subtype/supertype
> graph of that entity." This restriction is an unnecessary limitation.
> The attribute could easily be qualified to the correct attribute by the
> name of the supertype using a group qualifier.
> ACCEPTED: Will need to introduce new syntax for inverse attributes to
> allow such qualification, i.e. inverse inv: sub for sup1/attrib
>
> On verifying this syntax change I have noticed that the comment and the
> accepted resolution were wrong. It is not possible to use a group
> qualifier in this way. According to EXPRESS the identifier after a group
> qualifier shall be the name of an entity, in the case of the accepted
> resolution an attribute identifier is given after the group qualifier. I
> guess we could change the accepted resolution to allow a attribute
> qualifier and have:
> INVERSE
>   inv : sub FOR sup1.attrib;
>
> Suggestions etc.
>
> Phil.
>
> PS The reason for this comment was because TC2 had explicitly banned
> inverses to ambiguous attribute identifiers (This I think was a good
> move but other obviously didn't!). This resolution was an attempt to
> allow these references again, but this time to ensure there was no
> ambiguity by de-referencing the attribute identifier in the context of
> the entity in which it was declared.
>