[wg11] Is an empty extensible select a specialization of anothertype?

Lothar Klein lothar.klein at lksoft.com
Mon May 15 04:01:18 EDT 2006


David,

Thanks for your feedback.
I should have added the schema structure to make things more clear.
Here it is:

SCHEMA Shape_property_assignment_arm
  ...
  ENTITY Shape_element; ...
     containing_shape : Item_shape; ...
END_SCHEMA;


SCHEMA Non_feature_shape_element_arm
  USE FROM Shape_property_assignment_arm; ...

  TYPE ee_product_definition_with_annotation_elements = EXTENSIBLE
     GENERIC_ENTITY SELECT ;
  END_TYPE;
   ...
  ENTITY Non_feature_shape_element
    SUBTYPE OF (Shape_element); ...
     SELF\Shape_element.containing_shape RENAMED scope :
        ee_product_definition_with_annotation_elements; ...
  ...
END_SCHEMA;

And there are higher level schemas which uses
Non_feature_shape_element_arm and extend
ee_product_definition_with_annotation_elements with subtypes of
Item_shape (only).

The question is whether or not schema Non_feature_shape_element_arm is
valid as it is without looking to the other higher level schemas.

Lothar

-- 
// 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

Sunday, May 14, 2006, 10:56:28 PM, you wrote:
> My two cents are that this EXPRESS is invalid if that's all in the schema
> under consideration. My understanding is that the SELECT being extensible
> generic entity means any entity type can be added. So, it seems to me it is
> not a specialization of Item_shape but is in fact a generalization of
> Item_shape - and every other entity type in the schema.

> However, if the SELECT was completed to contain only Item_shape subtypes,
> then it would be legal - that's clear. It looks to me like if you just added
> Item_shape to the select list you'd be legal per P11 right now. You could
> write a rule to eliminate a direct instance of Item_shape from valid
> instantiations in the modules that use this one if that's the intent.

> Part 11 does not seem clear on whether the "select of a,b,c is
> specialization of a if b and c are subtypes" is true for extensible select
> types or not.

> It does look like a useful construct in the modular architecture though.
> Hope it's easy to enable in P11.

> Cheers,
> David

>> -----Original Message-----
>> From: wg11-bounces at steptools.com 
>> [mailto:wg11-bounces at steptools.com] On Behalf Of Lothar Klein
>> Sent: 13 May 2006 16:47
>> To: wg11 at steptools.com
>> Subject: [wg11] Is an empty extensible select a 
>> specialization of anothertype?
>> 
>> 
>> Please find below a discussion on the AP210 bugzilla system to the
>> question whether or not an empty extensible select is a specialisation
>> of another type in EXPRESS?
>> 
>> Do you think we have to do something on this?
>> 
>> -- 
>> // Lothar Klein, LKSoftWare GmbH
>> // Steinweg 1, 36093 Kuenzell, Germany
>> // +49 661 933933-0, Fax: -2
>> // url: http://www.lksoft.com
>> 
>> 
>> Opened: 2006-04-29 17:31 by Lothar Klein
>> 
>> While looking to bug #2038 I detected another severe Express 
>> issue which is
>> clearly wrong, even if the Express compiler don't catch it 
>> yet. Currently we have:
>> 
>>   ENTITY Shape_element; ...
>>       containing_shape : Item_shape; ...
>> 
>>   ENTITY Non_feature_shape_element
>>     SUBTYPE OF (Shape_element); ...
>>       SELF\Shape_element.containing_shape RENAMED scope :
>> ee_product_definition_with_annotation_elements; ...
>> 
>>   TYPE ee_product_definition_with_annotation_elements = EXTENSIBLE
>> GENERIC_ENTITY SELECT ;
>>   END_TYPE; -- ee_product_definition_with_annotation_elements
>> 
>> ee_product_definition_with_annotation_elements is not a 
>> specialization of
>> Item_shape and so this express is not valid. But fortunately 
>> all the elements in
>> the extensions are Item_shape.
>> 
>> Proposal is to simply remove the redeclaration of 
>> containing_shape in the
>> Non_feature_shape_element and remove the select with its extensions.
>> 
>> 
>> ------- Additional Comment #1 From Tom Thurman 2006-04-30 
>> 15:10 -------
>> 
>> Actually this is not a problem in EXPRESS.  As long as the 
>> items are subtypes 
>> of Item_shape the EXPRESS is legal.
>> 
>> 
>> ------- Additional Comment #2 From Lothar Klein 2006-04-30 
>> 17:59 -------
>> 
>> Sorry, but this is really a bug and I have to re-open it. We 
>> may not be able to
>> solve this for ed2.
>> 
>> The items are only added at a later time. Within schema
>> Non_feature_shape_element_arm the extenable select
>> ee_product_definition_with_annotation_elements can't be 
>> considered as a
>> specialization of Item_shape. At least I can't see which 
>> statement in part11,
>> e.g. "9.2.7 Specialization" would allow this. If you see then 
>> please provide here.
>> 
>> 
>> ------- Additional Comment #3 From Tom Thurman 2006-05-01 
>> 12:32 -------
>> 
>> re-assign to Lothar to write SEDS against part 11 for clarification.
>> -----------------------
>> here is the definition of a SELECT type:
>> 8.4.2 Select data type
>> A select data type defines a data type that enables a choice 
>> among several 
>> named data types.
>> The select data type is a generalization of these named data 
>> types in its 
>> domain. The defined
>> type for which the select data type is the underlying 
>> representation, may add 
>> constraints on
>> its domain by declaring local rules. A select data type may 
>> be extensible or 
>> not.
>> -------------
>> here is the applicable clause from 9.2.7:
>> a select of a, b, c is a specialization of a select of d, e, 
>> f if a, b, c are 
>> specializations of
>> d, e, f;
>> ? a select of a, b, c is a specialization of a supertype if 
>> a, b, c are 
>> subtypes of the supertype;
>> ------------------
>> The interpretation of this by the compiler writers is that 
>> the bullet from 
>> 9.2.6 that specifies the behavior of select applies.
>> I have seen this behavior where the compiler will allow the 
>> use of EXTENSIBLE 
>> SELECT as long as the leaf elements are subtypes of the original type 
>> referenced by the attribute.
>> I would suggest you write a SEDS against part 11, clause 9.2.7 to get 
>> clarification or maybe a note to the wg11 exploder.
>> --------------------------
>> Another way of looking at this is the "expectation" that the 
>> modules are all 
>> compiled into a long form and this is something that will be 
>> resolved there.
>> ------------------------------
>> 
>> _______________________________________________
>> wg11 mailing list
>> wg11 at steptools.com
>> http://lists.steptools.com/mailman/listinfo/wg11
>> 


> _______________________________________________
> wg11 mailing list
> wg11 at steptools.com
> http://lists.steptools.com/mailman/listinfo/wg11



More information about the wg11 mailing list