Need for expertise

[Phil Spiby]

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
>