Need for expertise
Jochen Haenisch
Jochen.Haenisch at epmtech.jotne.com
Fri Nov 22 11:41:11 EST 2002
Hi everybody,
as I need to compile the schema, also I had a look at how to specify the
required semantics. My suggestion for correcting the entity is the
following:
ENTITY double_toleranced_measure_item
SUBTYPE OF (compound_representation_item);
-- JH SELF\compound_representation_item.item_element : LIST [2 : 2] OF
representation_item;
DERIVE
tolerance_range : value_range :=
SELF\compound_representation_item.item_element[2];
toleranced_measure_value : measure_representation_item :=
SELF\compound_representation_item.item_element[1];
(* JH: start new where-rule *)
WHERE
WR1: SIZEOF(SELF\compound_representation_item.item_element) = 2;
WR2: 'LIST_REPRESENTATION_ITEM' IN
TYPEOF(SELF\compound_representation_item.item_element);
(* JH: end new where-rule *)
END_ENTITY;
That is, no redeclaration; instead two where-rules:
- one to ensure that the aggregate has exactly two members;
- the other one to ensure that the attribute is of type LIST.
Does this fulfil the requirements?
Best regards, Jochen.
____________________________________________________________
Jochen Haenisch E-mail: Jochen.Haenisch at epmtech.jotne.com
EPM Technology AS Home of the EXPRESS Data Manager
P.O Box 6629 Etterstad Tel: Int + 47 23 17 17 26; mobile: Int + 47
922 60 274
N-0607 Oslo Fax: Int + 47 23 17 17 01
Norway Web: http://www.epmtech.jotne.com
> -----Original Message-----
> From: Phil Spiby [SMTP:Phil.Spiby at eurostep.com]
> Sent: 21. november 2002 10:58
> To: 'Lothar Klein'; owner-wg11 at steptools.com
> Cc: 'Pascal Huau'; 'WG11'; 'Jochen Haenisch'; 'Thomas Hendrix';
> 'Nettles, Darla'
> Subject: RE: Re[4]: Need for expertise
>
> Lothar,
>
> OK Lothar, you are right according to the rules on specialization as
> defined in the EXPRESS language.
> But I still believe these rules are wrong!
>
> According to the rules on specialization
> TYPE sel = SELECT(list_of_x, set_of_x)
>
> list_of_x is not a specialisation of sel, but my_list_of_x is if
> TYPE my_list_of_x = sel
> WHERE NOT ('MYSCHEMA.SET_OF_X' IN TYPEOF(SELF));
>
> BUT the value space for my_list_of_x and list_of_x are exactly the same.
>
> You say E3 is in the sky, I would argue that yes it is dead but the
> ideas that were in it regarding type structures were well founded on the
> principles of ISO 11404, instead of the ad-hoc ideas of specialization
> for which we have had to introduce TC2 to patch up (but not fix!). I
> believe we missed an opportunity to fix EXPRESS so that it would work
> correctly when E3 was killed.
>
> Pascal,
>
> If you make the change following my option 3, it should meet your
> requirements on constraining the redeclared attribute, and also make it
> compatible with these rules on specialization.
> TYPE list_of_two_representation_items = list_representation_item;
> WHERE
> HIINDEX(SELF) = 2;
> END_TYPE;
> Remember that the HIBOUND and LOBOUND functions will return the values ?
> And 0 respectively, since this method of constraint does not allow you
> to alter the type definition itself
> I know list_of_two_representation_items is not as clear to the end users
> as you would want, but the meaning with respect to value spaces is
> exactly the same, and is consistent with these awful rules on
> specialization.
>
> Phil
>
> PS The reason E3 was delayed so long was because we were trying to solve
> these issues on the type structure, not the dynamics stuff, which seemed
> to have upset most people, but was added fairly quickly based directly
> on the ideas in UML and CORBA. There are still a lot of problems with
> the type structure even following E2, which are usually soluble, but
> require building some odd structures to work around, such as the above!
>
> > -----Original Message-----
> > From: Lothar Klein [mailto:lothar.klein at lksoft.com]
> > Sent: 20 November 2002 18:58
> > To: owner-wg11 at steptools.com; Phil Spiby
> > Cc: 'Pascal Huau'; 'WG11'; 'Jochen Haenisch'; 'Thomas
> > Hendrix'; 'Nettles, Darla'
> > Subject: Re[4]: Need for expertise
> >
> >
> > All,
> > I wonder whether such discussions should be held in the WG11
> > exploder or if they should be moved into some EXPRESS
> > exploder. But since such issues may affect all implementation
> > methods they are addressing the WG11 community as a whole. Agreed?
> >
> >
> > Phil,
> > You write below
> > "... But LIST [2:2] OF x is not defined to be a specialization
> > of list_of_x ...".
> > This makes me thinking that I'm right since I was talking on
> > EXPRESS as it stands right now (E1+TC1+TC2+E2) but not on E3
> > in the sky.
> >
> > Another issue is if this logic is useful or if it should
> > be changed somehow as you indicate. Maybe it is - maybe not -
> > I don't care. For me it is important that we have a
> > consistent logic throughout all WG11 standards.
> >
> > For p21, SDAI and also for EXPRESS (via typeof) the name of a
> > defined type carries essential information. Let me change
> > your model slightly to make this clear:
> >
> > ENTITY X; END_ENTITY;
> >
> > ENTITY SUPER_X;
> > Attrib : sel;
> > END_ENTITY;
> >
> > ENTITY SUB_X SUBTYPE OF SUPER_X;
> > SELF\super.Attrib : LIST [2:2] OF X;
> > END_ENTITY;
> >
> > TYPE sel = SELECT(a_list, b_list);
> > END_TYPE;
> >
> > TYPE A_LIST = LIST OF X;
> > END_TYPE;
> >
> > TYPE B_LIST = LIST OF X;
> > END_TYPE;
> >
> > In part21 we can now write
> >
> > #111=SUPER_X( A_LIST( (#11,#12) ) );
> > #222=SUPER_X( B_LIST( (#21,#22) ) );
> > #333=SUB_X( ??? (#31,#32) ? );
> >
> > Instances #111 and #222 clearly states whether they contain
> > an A_LIST or a B_LIST. If SUB_X would be valid, then what is
> > the type of attribute Attrib in #333? And what would the
> > EXPRESS typeof says to this?
> >
> > Lothar
> >
> > Wednesday, November 20, 2002, 7:00:53 PM, you wrote:
> > > Lothar,
> >
> > > Sorry but you are wrong! (at least in my view of the world which is
> > > affected by the fixes developed to these problems in the original
> > > EXPRESS 2 where we clearly defined type aliasing, subtyping and type
> > > specialization)
> >
> > > Let's ignore the P21 implications to start with, and look
> > at what is
> > > happening in a simplified model.
> >
> > > ENTITY super;
> > > Attrib : sel;
> > > END_ENTITY;
> >
> > > ENTITY sub SUBTYPE OF super;
> > > SELF\super.Attrib : LIST [2:2] OF X;
> > > END_ENTITY;
> >
> > > TYPE sel = SELECT(list_of_x, set_of_x);
> > > END_TYPE;
> >
> > > TYPE list_of_x = LIST OF X;
> > > END_TYPE;
> >
> > > TYPE set_of_x = SET OF X;
> > > END_TYPE;
> >
> > > As you can see the problem is the same (although we have kept away
> > > from the issues of what X is and how many models of
> > tolerance are in
> > > STEP, and angles on the head of a pin for that matter!)
> >
> > > The attribute super.attrib has as it's value space all
> > list_of_x and
> > > all set_of_x, we can define a sub-value space within this to be
> > > list_of_x. The value space list_of_x contains all lists
> > from HIINDEX =
> > > 0 (i.e. the empty list) through to HIINDEX = integer max.
> > Again within
> > > this value space we can define a sub value space which is the those
> > > lists of x with just two elements. Given the above reasoning, the
> > > redeclaration is constraining the allowed value space for this
> > > attribute to be the sub sub value space containing lists of two
> > > elements of X, and as such is allowed.
> >
> > > The above argument would hold for correctly constructed Ada
> > version of
> > > the structure and should hold for any data type structures which
> > > follow ISO 11404, Language independent data types.
> >
> > > The problem with EXPRESS, as it now stands (probably
> > staggers is the
> > > correct phrase here!) is that we define this concept called
> > > specialisation and don't clearly define what it really means with
> > > respect to value spaces and assignment compatibility. There
> > are some
> > > rules defining what specialization means based on the structure and
> > > names in the EXPRESS language, but this leads to problems.
> > Such as our
> > > type sel being a specialization of SELECT(list_of_x,
> > set_of_x), when
> > > really what we want is just to name the select!
> >
> > > The problem raised by Lothar (and now by Per Lovmo changing
> > his mind)
> > > comes from the issue Is LIST [2:2] OF x a specialisation of
> > list_of_x
> > > Now according to the rules on specialisation laid down in EXPRESS
> > > (including the TCs)
> > > list_of_x is a specialisation of LIST OF x
> > > and LIST [2:2] OF x is also a specialisation of LIST OF x
> > > But LIST [2:2] OF x is not defined to be a specialization
> > of list_of_x
> >
> > > There are three solutions to this issue:
> > > 1: Allow any type to be declared in select types, this
> > would allow our
> > > type sel to be declared as TYPE sel = SELECT(LIST OF x, SET OF x);
> > > END_TYPE
> > > In which case LIST [2:2] OF x is then an allowed redeclaration.
> >
> > > 2: Clarify the type structure as done in the original
> > EXPRESS 2 (now
> > > EXPRESS 3) using the keywords IS, IS SUBTYPE and IS SPECIALIZATION.
> > > Where:
> > > IS means the two types are exactly the same and is used for naming
> > > only. IS SUBTYPE means that one type has a value space within the
> > > value space of the other and assignment compatibility is assured in
> > > one direction and possible in the other if the subsetting
> > constraints
> > > are met. IS SPECIALIZATION means that the two types are
> > based on the
> > > same value space (possibly subsetted) but there is no assignment
> > > compatibility between the values without coercion.
> > > It is highly unlikely that this solution will be adopted
> > since it would
> > > be a major delay to E2, although it would fix all these
> > issues (and many
> > > others which are known to the EXPRESS committee but not
> > publicised for
> > > obvious reasons ;-)
> >
> > > 3: Restructure the model slightly to ensure the required
> > constraint is
> > > applied and this clearly follows the specialisation structure. i.e.
> > > ENTITY sub SUBTYPE OF super;
> > > SELF\super.Attrib : list_of_2x;
> > > END_ENTITY;
> >
> > > TYPE list_of_2x = list_of_x;
> > > WHERE
> > > HIINDEX(SELF) = 2;
> > > END_TYPE;
> >
> > > Phil
> >
> > >> -----Original Message-----
> > >> From: Lothar Klein [mailto:lothar.klein at lksoft.com]
> > >> Sent: 19 November 2002 17:43
> > >> To: owner-wg11 at steptools.com; Phil Spiby
> > >> Cc: 'Pascal Huau'; 'WG11'; 'Jochen Haenisch'; 'Thomas
> > >> Hendrix'; 'Nettles, Darla'
> > >> Subject: Re[2]: Need for expertise
> > >>
> > >>
> > >> I wonder how this example could be valid according to the
> > >> general EXPRESS re-declaration philosophy on attributes. So
> > >> far the domain of a re-declared attribute was always a
> > >> specialization of the previous domain.
> > >>
> > >> An instance of a compound_representation_item in a p21-file looks
> > >> like
> > >> this:
> > >>
> > >> #2373=COMPOUND_REPRESENTATION_ITEM('...',LIST_REPRESENTATION_I
> > >> TEM((#2375,#2376)));
> > >>
> > >> But if we would follow the given example then we should
> > >> decode the subtype as
> > >>
> > >> #2373=DOUBLE_TOLERANCED_MEASURE_ITEM('...',(#2375,#2376));
> > >>
> > >> which is quite different.
> > >> This example makes clear that the domain of "item_element" in
> > >> the subtype is no longer a specialization of the supertype.
> > >>
> > >>
> > >> If someone thinks this is no problem then let us define one
> > >> more entity, e.g.:
> > >>
> > >> ENTITY blablabla_item
> > >> SUBTYPE OF (compound_representation_item);
> > >> SELF\compound_representation_item.item_element : SET[2:2]
> > >> OF representation_item; END_ENTITY;
> > >>
> > >> And now please write down an instance which is both, a
> > >> blablabla_item and a double_toleranced_measure_item. Would
> > >> like to see this.
> > >>
> > >>
> > >> So my answer to Pascal is:
> > >> EXPRESS unfortunately does not support re-declaration of
> > >> these kind of defined_types such as list_representation_item
> > >> and set_representation_item. So you better write a rule in
> > >> the subtype to further constrain the population.
> > >>
> > >> Lothar
> > >>
> > >> P.S: Besides the EXPRESS problems I have some doubts of
> > >> defining one more AIM-entity on tolerances. Already today we
> > >> have in-compatible tolerance models in AP210 and 214. The 210
> > >> tolerance model is about 3 times more complex than the 214
> > >> model - but neither of them got implemented till today as far
> > >> as I know. I wonder what is the benefit to have one more
> > >> model? And please don't forget the outstanding SEDS on part47.
> > >>
> > >>
> > >> Tuesday, November 19, 2002, 12:01:01 PM, you wrote:
> > >> > Pascal,
> > >>
> > >> > According to TC2 your code should be allowed.
> > >> > However, please realise that TC2 never seems to have made it to
> > >> > Geneva! Dave and I asked a number of times about this and
> > >> never got a
> > >> > straight answer from Teresa.
> > >>
> > >> > Therefore it is highly likely that tools will not yet
> > support this
> > >> > level of complexity until Ed2 is released (including all the TC2
> > >> > changes). My tool (Eep) doesn't support this at present, it
> > >> is on my
> > >> > list of things to do!
> > >>
> > >> > Phil
> > >>
> > >> > -----Original Message-----
> > >> > From: Pascal Huau [mailto:pascalhuau at goset.asso.fr]
> > >> > Sent: 19 November 2002 08:57
> > >> > To: Phil Spiby; WG11; Jochen Haenisch
> > >> > Cc: Thomas Hendrix; Nettles, Darla
> > >> > Subject: Need for expertise
> > >>
> > >>
> > >> > Dear experts,
> > >>
> > >>
> > >> > in a module, we define:
> > >>
> > >> > ENTITY double_toleranced_measure_item
> > >> > SUBTYPE OF (
> > >> >
> > >> <file:///D:/Utilisateurs/Huau/Modules/XML_reposit/stepmod/data
> > >> /resources
> > >> >
> > >> /representation_schema/representation_schema.xml#representatio
> > >> n_schema.c
> > >> > ompound_representation_item> compound_representation_item);
> > >> > SELF\
> > >> >
> > >> <file:///D:/Utilisateurs/Huau/Modules/XML_reposit/stepmod/data
> > >> /resources
> > >> >
> > >> /representation_schema/representation_schema.xml#representatio
> > >> n_schema.c
> > >> > ompound_representation_item>
> > >> compound_representation_item.item_element :
> > >> > LIST[2:2] OF
> > >> >
> > >> <file:///D:/Utilisateurs/Huau/Modules/XML_reposit/stepmod/data
> > >> /resources
> > >> >
> > >> /representation_schema/representation_schema.xml#representatio
> > >> n_schema.r
> > >> epresentation_item>> representation_item;
> > >> > DERIVE
> > >> > tolerance_range :
> > >> >
> > >> <file:///D:/Utilisateurs/Huau/Modules/XML_reposit/stepmod/data
> > >> /modules/e
> > >> >
> > >> xtended_measure_representation/sys/5_mim.xml#extended_measure_
> > >> representa
> > >> > tion_mim.value_range> value_range :=
> > >> > SELF\compound_representation_item.item_element[2];
> > >> > toleranced_measure_value :
> > >> >
> > >> <file:///D:/Utilisateurs/Huau/Modules/XML_reposit/stepmod/data
> > >> /resources
> > >> >
> > >> /qualified_measure_schema/qualified_measure_schema.xml#qualifi
> > >> ed_measure
> > >> > _schema.measure_representation_item>
> > measure_representation_item :=
> > >> > SELF\compound_representation_item.item_element[1];
> > >> > END_ENTITY;
> > >>
> > >>
> > >>
> > >>
> > >> > The definition in P43 of compound_representation_item is:
> > >>
> > >> > TYPE compound_item_definition = SELECT
> > >> > (
> > >> >
> > >> <file:///D:/Utilisateurs/Huau/Modules/XML_reposit/stepmod/data
> > >> /resources
> > >> >
> > >> /representation_schema/representation_schema.xml#representatio
> > >> n_schema.l
> > >> > ist_representation_item> list_representation_item,
> > >>
> > >> >
> > >> <file:///D:/Utilisateurs/Huau/Modules/XML_reposit/stepmod/data
> > >> /resources
> > >> >
> > >> /representation_schema/representation_schema.xml#representatio
> > >> n_schema.s
> > >> > et_representation_item> set_representation_item); END_TYPE;
> > >>
> > >> > TYPE list_representation_item = LIST[1:?] OF
> > >> >
> > >> <file:///D:/Utilisateurs/Huau/Modules/XML_reposit/stepmod/data
> > >> /resources
> > >> >
> > >> /representation_schema/representation_schema.xml#representatio
> > >> n_schema.r
> > >> epresentation_item>> representation_item;
> > >> > END_TYPE;
> > >>
> > >> > TYPE set_representation_item = SET[1:?] OF
> > >> >
> > >> <file:///D:/Utilisateurs/Huau/Modules/XML_reposit/stepmod/data
> > >> /resources
> > >> >
> > >> /representation_schema/representation_schema.xml#representatio
> > >> n_schema.r
> > >> epresentation_item>> representation_item;
> > >> > END_TYPE;
> > >>
> > >> > ENTITY compound_representation_item
> > >> > SUBTYPE OF (
> > >> >
> > >> <file:///D:/Utilisateurs/Huau/Modules/XML_reposit/stepmod/data
> > >> /resources
> > >> >
> > >> /representation_schema/representation_schema.xml#representatio
> > >> n_schema.r
> > >> epresentation_item>> representation_item);
> > >> > item_element :
> > >> >
> > >> <file:///D:/Utilisateurs/Huau/Modules/XML_reposit/stepmod/data
> > >> /resources
> > >> >
> > >> /representation_schema/representation_schema.xml#representatio
> > >> n_schema.c
> > >> > ompound_item_definition> compound_item_definition; END_ENTITY;
> > >>
> > >>
> > >>
> > >> > Presently, EPM parser raises the following error for
> > >> > double_toleranced_measure_item:
> > >> > ERROR : Line 1037: Illegal attribute redeclaration.
> > >>
> > >> > Redeclaring attribute:
> > >> DOUBLE_TOLERANCED_MEASURE_ITEM.ITEM_ELEMENT in
> > >> > line: 1037
> > >>
> > >> > Redeclared attribute:
> > >> COMPOUND_REPRESENTATION_ITEM.ITEM_ELEMENT in line:
> > >> > 28770
> > >>
> > >> > Redeclaration from aggregate type to simple type is illegal
> > >>
> > >>
> > >>
> > >> > My questions are the following:
> > >>
> > >> > - does the present definition of
> > >> double_toleranced_measure_item conform
> > >> > to Express Ref language (ed2 or ed1)?
> > >>
> > >> > - if not, how should we specify the constraint on the
> > cardinality of
> > >> > double_toleranced_measure_item.item_element?
> > >>
> > >>
> > >>
> > >> > Thanks in advance for your help,
> > >>
> > >>
> > >>
> > >> > Pascal Huau
> > >> > Association GOSET
> > >> > 107, 111 avenue Clemenceau
> > >> > 92000 Nanterre
> > >> > France
> > >> > (tel: +33 1 47252222)
> > >>
> > >>
> > >>
> > >> --
> > >> // Lothar Klein, LKSoftWare GmbH
> > >> // Steinweg 1, 36093 Kuenzell, Germany
> > >> // +49 661 933933-0, Fax: -2
> > >> // mailto:lothar.klein at lksoft.com http://www.lksoft.com
> > >>
> >
> >
> > --
> > // Lothar Klein, LKSoftWare GmbH
> > // Steinweg 1, 36093 Kuenzell, Germany
> > // +49 661 933933-0, Fax: -2
> > // mailto:lothar.klein at lksoft.com http://www.lksoft.com
> >
More information about the wg11
mailing list