[wg11] RE: P11e2: FDIS -> IS
Phil Spiby
Phil.Spiby at Eurostep.com
Mon Jul 5 11:38:23 EDT 2004
Hei Jochen,
Finally got around to working on these!
My comments are inserted into your message.
Phil
-----Original Message-----
From: Jochen Haenisch [mailto:Jochen.Haenisch at epmtech.jotne.com]
Sent: 19 May 2004 18:10
To: 'Phil Spiby'
Cc: 'WG11 exploder'; 'expressIF at tc184-sc4.org'
Subject: P11e2: FDIS -> IS
Hei Phil,
attached are recently forwarded SEDS. 866, 910, 911 may be resolved for the
IS-version; 915 maybe not. You will have an opinion on that :-)
<PS>
My view on the SEDS is that:
866 Accepted Changed in IS document
910 Disagree! The proposed change does not fix the problem
since in E4 the attribute is not RENAMED, it is a recdeclaration of one
renamed earlier. I think we should be more explicit with how we handle the
different cases in this area, for example we can change an explicit
attribute into a renamed derived attribute pointing to a subtype with a
derivation. This is not handled in the current FDIS or the proposed solution
in the SEDS.
911 Accepted Proposed input expected from Jochen.
</PS>
In addition the items below.
----------------------------------------------------------------------------
-------------------
The type labels issue that you just sent an email about.
<PS>
Of course I agree on this!
</PS>
----------------------------------------------------------------------------
-------------------
On page 226:
Could you verify that WR2 for domain2_approval should be removed?
<PS>
Yes.
But we also need to change specific_approval as follows:
TYPE specific_approval = domain2_approval;
END_TYPE;
</PS>
----------------------------------------------------------------------------
-------------------
Also: These examples without entities: according to the pruning of
non-referenced defined types, the 1994-schemas would indeed be empty. There
should be a disclaimer accordingly, or three dots after SCHEMA and before
END_SCHEMA.
<PS>
Do we have a complete list of the examples which need changing?
</PS>
======================================================
Günther had the following (I have only scanned them ...): Chapter G.3.2,
page 206, Example 1: The single quotes used there are typographical quotes
not ASCII(27) ! Therefore a cut and paste of examples leads to errors. Note
that this kind of wrong quoting character is used in other places as well.
<PS>
Agreed.
Will change where I find them.
</PS>
----------------------------------------------------------------------------
-------------------
On page 224:
Example 1: The enumeration "gender" uses the reserved word "unknown" !
<PS>
Will change to not-known
</PS>
----------------------------------------------------------------------------
-------------------
Chapter G.5.5, page 230, Example 1 and paragraph above example: Example does
not compile, because reference to "binary_entity_relationship" in SUBTYPE OF
instead of "binary_relationship". Paragraph above refers also to the wrong
entity_name.
<PS>
Agreed will be changed.
</PS>
Furthermore not clear how to handle a case of
...
end_one : SET OF GENERIC_ENTITY
...
or
...
end_one : AGGREGATE OF GENERIC_ENTITY
...
What would be the rules in these cases?
<PS>
The rules say create a select type, but this is not possible for the
aggregate cases. I guess we would have to create named types for each
aggregate declared in subtypes, then include these into the select.
</PS>
----------------------------------------------------------------------------
-------------------
Chapter G, especially ordering of G.5.5 and G.5.3.2 :
There can be cases constructed where the normal ordering of steps leads to
wrong results.
-------------------------------------------------------------------------
SCHEMA import; -- Example Test_G55_Ex_2.txt
ENTITY action_assignment ABSTRACT;
set_of_items : SET [1 : ?] OF action_items;
items : action_items;
END_ENTITY;
TYPE configuration_effectivity = NUMBER;
END_TYPE;
TYPE action_item_203e2 = SELECT BASED_ON action_items WITH
(configuration_effectivity);
END_TYPE;
TYPE action_items = EXTENSIBLE GENERIC_ENTITY SELECT ;
END_TYPE;
TYPE action_items_2 = EXTENSIBLE GENERIC_ENTITY SELECT
(action_assignment);
END_TYPE;
ENTITY applied_action_assignment
SUBTYPE OF (action_assignment);
SELF\action_assignment.set_of_items : SET [1 : 5] OF action_items;
SELF\action_assignment.items : configuration_effectivity;
END_ENTITY;
END_SCHEMA;
-------------------------------------------------------------------------
Doing G.5.3.2 first converts extensible Selects into standard selects. By
this step G.5.5 cannot be applied since the "GENERIC_ENTITY" is no longer
there.
<PS>
Not sure about the issue here!
The GENERIC_ENTITY in the select structure is a constraint on the extension
of the type, so if the E2 schema is correct applying G.5.3.2 generates the
correct results. The constraint has no meaning under G.5.5, which is only
dealing with attributes of abstract entities.
</PS>
----------------------------------------------------------------------------
-------------------
Chapter G.4.4 :
It is not explicitly written, that the pruning step has to be iterative
until no more changes occur. Since pruning of rules could lead to things in
the artifact schema which should not be there. Example below:
-------------------------------------------------------------------------
SCHEMA s1;
ENTITY e1;
END_ENTITY;
ENTITY thing;
END_ENTITY;
ENTITY function_thing_local;
END_ENTITY;
ENTITY function_thing_inp;
END_ENTITY;
ENTITY e2 SUBTYPE OF (e1);
END_ENTITY;
ENTITY e3 SUBTYPE OF (e1);
END_ENTITY;
SUBTYPE_CONSTRAINT sc_total_over FOR e1;
TOTAL_OVER (e2, e3);
END_SUBTYPE_CONSTRAINT;
RULE e2_and_e3 FOR (e2, e3);
-- rule body
WHERE
wr1 : f2(TRUE);
END_RULE;
FUNCTION f1(inp : function_thing_inp) : BOOLEAN;
LOCAL
a : function_thing_local;
END_LOCAL;
RETURN(TRUE);
END_FUNCTION;
FUNCTION f2(inp : BOOLEAN) : BOOLEAN;
LOCAL
a : function_thing_local;
END_LOCAL;
RETURN(TRUE);
END_FUNCTION;
END_SCHEMA; -- end s1
SCHEMA import;
REFERENCE FROM s1 (function_thing_inp);
REFERENCE FROM s1 (e2);
END_SCHEMA; -- end import
------------------------------------------------------------------------
Without iteration this would lead to inclusion of "f2" and
"function_thing_local" which are per se not part of the longform. To get rid
of "function_thing_local" a pruning of entities which are not referenced and
not brought into the schema through USE_FROM or REFERENCE_FROM has to take
place.
<PS>
Do you have some proposed words which can be used here Guenter?
</PS>
======================================================
Ed, Tom Kramer and Peter Denno had the following one:
In Part 11.2:2003, clause 9.2.5.2, after the normative text, the following
NOTE
is to be found:
"NOTE The phrase ONEOF(a,b,c) reads in natural language as 'an instance
shall
consist of one and only one of the entity data types a,b,c.'"
The NOTE does not correctly convey the intent of the normative text.
Proposed change:
Either: The words "one and only one" should be replaced by "at most one"
or: the words "shall consist of one and only one" should be replaced by
"shall not consist of more than one". (I prefer the latter.)
<PS>
Changed to "at most one"
</PS>
======================================================
Darla has this one:
Part11e2FDIS says in 9.5.3.2
If a generic data type is used as the result type of a function, or as the
type of a local variable within a function or procedure, type labels [sic]
references are required for this usage.
should be written like this:
If a generic data type is used as the result type of a function, or as the
type of a local variable within a function or procedure, type label
references are required for this usage.
<PS>
Changed (in aggregate and generic entity also!)
</PS>
======================================================
Regards,
Jochen
<<SEDS-866-STEP-Part11ed2FDIS.txt>>
<<SEDS-911-10303-11-FDIS-ed2-RootPrimarySchemaDefs.txt>>
<<SEDS-910-STEP-11ed2-attribute-renaming.txt>>
<<SEDS-915-10303-11-FDIS-ed2-Use-from-all.txt>>
____________________________________________________________
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
More information about the wg11
mailing list