Need for expertise
Lothar Klein
lothar.klein at lksoft.com
Wed Nov 20 13:58:09 EST 2002
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