From terrylr at blauedonau.com  Mon Apr 18 15:32:09 2005
From: terrylr at blauedonau.com (terry l. ridder)
Date: Mon Apr 18 14:18:32 2005
Subject: [step-os] ap203 edition 1 question
Message-ID: <Pine.LNX.4.62.0504181423480.7857@johann.blauedonau.com>

hello;

would someone know which versions/editions of

--ISO 10303-41
--ISO 10303-42
--ISO 10303-43
--ISO 10303-44
--ISO 10303-501
--ISO 10303-502
--ISO 10303-507
--ISO 10303-509
--ISO 10303-510
--ISO 10303-511
--ISO 10303-512
--ISO 10303-514

were used with 10303-203-aim-short.exp to create 10303-203-aim-long.exp?

the reason i ask i have been testing my updated and rewritten parts of
the nist scl3.2. i have also updated nist shtolo.

i am trying to reconcile the differences between the ap203 long form i
create and the 'official' ap203 long form.

i know there is a difference in how the 'official' ap203 and my ap203
long forms are pruned. this does not account for all the differences.

i would like to test with the same versions/editions as used to create
the 'official' ap203 long form to see what differences remain
unaccounted for.

-- 
terry l. ridder ><>
From david.price at eurostep.com  Wed Apr 20 05:20:25 2005
From: david.price at eurostep.com (David Price)
Date: Wed Apr 20 04:04:34 2005
Subject: [step-os] ap203 edition 1 question
In-Reply-To: <Pine.LNX.4.62.0504181423480.7857@johann.blauedonau.com>
Message-ID: <000a01c5458a$2fab5c50$2101a8c0@ESUKPC20>


I don't think this question is specific enough. Weren't there TCs (i.e. bug
fixes) and amendments to AP203 E1?

David

-----Original Message-----
From: step-os-bounces@step.nasa.gov [mailto:step-os-bounces@step.nasa.gov]
On Behalf Of terry l. ridder
Sent: 18 April 2005 20:32
To: step opensource
Subject: [step-os] ap203 edition 1 question

hello;

would someone know which versions/editions of

--ISO 10303-41
--ISO 10303-42
--ISO 10303-43
--ISO 10303-44
--ISO 10303-501
--ISO 10303-502
--ISO 10303-507
--ISO 10303-509
--ISO 10303-510
--ISO 10303-511
--ISO 10303-512
--ISO 10303-514

were used with 10303-203-aim-short.exp to create 10303-203-aim-long.exp?

the reason i ask i have been testing my updated and rewritten parts of
the nist scl3.2. i have also updated nist shtolo.

i am trying to reconcile the differences between the ap203 long form i
create and the 'official' ap203 long form.

i know there is a difference in how the 'official' ap203 and my ap203
long forms are pruned. this does not account for all the differences.

i would like to test with the same versions/editions as used to create
the 'official' ap203 long form to see what differences remain
unaccounted for.

-- 
terry l. ridder ><>
_______________________________________________
step-os mailing list
step-os@step.nasa.gov
http://step.nasa.gov/mailman/listinfo/step-os

From lothar.klein at lksoft.com  Wed Apr 20 05:54:54 2005
From: lothar.klein at lksoft.com (Lothar Klein)
Date: Wed Apr 20 04:39:22 2005
Subject: [step-os] ap203 edition 1 question
In-Reply-To: <000a01c5458a$2fab5c50$2101a8c0@ESUKPC20>
References: <Pine.LNX.4.62.0504181423480.7857@johann.blauedonau.com>
	<000a01c5458a$2fab5c50$2101a8c0@ESUKPC20>
Message-ID: <1133209874.20050420115454@lksoft.com>

I think the reason for these unspecific questions is that people not
directly involved in the STEP standardisation have real problems to
figure out their way through STEP.
The official web-site http://www.tc184-sc4.org/ is not really helping
for people who want to implement STEP.

The formal question to the question below is to go to www.ISO.ch and
buy there all the standards and technical corrigenda needed.
I still hope the time will come that it is possible to buy *ALL*
parts of 10303 on one CD for a reasonable price
and to have a regular update service, e.g. 2 times a year.

An almost complete and actual list of all EXPRESS schemas is available at
   http://www.steptools.com/sc4/archive/

In addition many of the schemas are available from
  http://sourceforge.net/projects/stepmod/

An overview of STEP products is available at
  http://pdesinc.aticorp.org/step_products.html

-- 
// Lothar Klein, LKSoftWare GmbH
// Steinweg 1, 36093 Kuenzell, Germany
// +49 661 933933-0, Fax: -2
// mailto:lothar.klein@lksoft.com   http://www.lksoft.com

Wednesday, April 20, 2005, 11:20:25 AM, you wrote:

> I don't think this question is specific enough. Weren't there TCs (i.e. bug
> fixes) and amendments to AP203 E1?

> David

> -----Original Message-----
> From: step-os-bounces@step.nasa.gov
> [mailto:step-os-bounces@step.nasa.gov]
> On Behalf Of terry l. ridder
> Sent: 18 April 2005 20:32
> To: step opensource
> Subject: [step-os] ap203 edition 1 question

> hello;

> would someone know which versions/editions of

> --ISO 10303-41
> --ISO 10303-42
> --ISO 10303-43
> --ISO 10303-44
> --ISO 10303-501
> --ISO 10303-502
> --ISO 10303-507
> --ISO 10303-509
> --ISO 10303-510
> --ISO 10303-511
> --ISO 10303-512
> --ISO 10303-514

> were used with 10303-203-aim-short.exp to create 10303-203-aim-long.exp?

> the reason i ask i have been testing my updated and rewritten parts of
> the nist scl3.2. i have also updated nist shtolo.

> i am trying to reconcile the differences between the ap203 long form i
> create and the 'official' ap203 long form.

> i know there is a difference in how the 'official' ap203 and my ap203
> long forms are pruned. this does not account for all the differences.

> i would like to test with the same versions/editions as used to create
> the 'official' ap203 long form to see what differences remain
> unaccounted for.


From terrylr at blauedonau.com  Wed Apr 20 09:45:47 2005
From: terrylr at blauedonau.com (terry l. ridder)
Date: Wed Apr 20 08:32:02 2005
Subject: [step-os] ap203 edition 1 question
In-Reply-To: <1133209874.20050420115454@lksoft.com>
References: <Pine.LNX.4.62.0504181423480.7857@johann.blauedonau.com>
	<000a01c5458a$2fab5c50$2101a8c0@ESUKPC20>
	<1133209874.20050420115454@lksoft.com>
Message-ID: <Pine.LNX.4.62.0504200828320.11068@johann.blauedonau.com>

hello;

reply intermixed below.

On Wed, 20 Apr 2005, Lothar Klein wrote:

> I think the reason for these unspecific questions is that people not
> directly involved in the STEP standardisation have real problems to
> figure out their way through STEP.
> The official web-site http://www.tc184-sc4.org/ is not really helping
> for people who want to implement STEP.
>

tc184-sc4.org is not the most friendly web site. it is slow and the way
it is layed out is in my opinion poor. despite that i have downloaded
many of the express language schemas from there.

>
> The formal question to the question below is to go to www.ISO.ch and
> buy there all the standards and technical corrigenda needed.
> I still hope the time will come that it is possible to buy *ALL*
> parts of 10303 on one CD for a reasonable price
> and to have a regular update service, e.g. 2 times a year.
>

i have several of the iso 10303 parts in pdf.

>
> An almost complete and actual list of all EXPRESS schemas is available at
>   http://www.steptools.com/sc4/archive/
>

i have the cvs 'dump' of the archives.

>
> In addition many of the schemas are available from
>  http://sourceforge.net/projects/stepmod/
>

i know of this project.

>
> An overview of STEP products is available at
>  http://pdesinc.aticorp.org/step_products.html
>

been there done that.

>
>

-- 
terry l. ridder ><>
From terrylr at blauedonau.com  Wed Apr 20 11:22:13 2005
From: terrylr at blauedonau.com (terry l. ridder)
Date: Wed Apr 20 10:08:27 2005
Subject: [step-os] ap203 edition 1 question
In-Reply-To: <000a01c5458a$2fab5c50$2101a8c0@ESUKPC20>
References: <000a01c5458a$2fab5c50$2101a8c0@ESUKPC20>
Message-ID: <Pine.LNX.4.62.0504200850150.11068@johann.blauedonau.com>

hello;

reply intermixed below.

On Wed, 20 Apr 2005, David Price wrote:

>
> I don't think this question is specific enough. Weren't there TCs (i.e. bug
> fixes) and amendments to AP203 E1?
>

i am not sure what you mean by the above.
does not matter since i spent the better part of two days finding the
various express language schemas and trying numerous combinations.
below is what i found that does produce iso 10303-203-aim-long.exp from
iso 10303-203-aim-short.exp

10303-203-aim-long.exp  is document WG3 N916
10303-203-aim-short.exp is document WG3 N915

10303-041 was document WG12 N304
10303-042 was document WG12 N415
10303-043 was document WG12 N291
10303-044 was document WG12 N228
10303-045 was document WG12 N256
10303-049 was document ACF1D64.exp     from tc184-sc4.org url 1.
10303-501 was document part501.exp     from tc184-sc4.org url 2.
10303-502 was document part502.exp     from tc184-sc4.org url 3.
10303-507 was document WG12 N285
10303-509 was document WG12 N262
10303-510 was document part510_is.exp  from tc184-sc4.org url 4.
10303-511 was document part-511_is.exp from tc184-sc4.org url 5.
10303-512 was document part512.exp     from tc184-sc4.org url 6.
10303-514 was document part514.exp     from tc184-sc4.org url 7.


note: 10303-042.exp (WG13 N415) had to be edited and the following add
to the SCHEMA topology_schema.
    REFERENCE FROM representation_schema(representation_item);


using the above documents does produce 10303-203-aim-long.exp (WG3
N916).

that being said. that document has errors.

specifically, function derive_dimensional_exponents is not pruned
correctly.

document WG3 N916 has function derive_dimensional_exponents as:

   FUNCTION derive_dimensional_exponents(x: unit): dimensional_exponents;
     LOCAL
       i      : INTEGER;
       result : dimensional_exponents := dimensional_exponents(0,0,0,0,0,0,
                 0);
     END_LOCAL;
     IF 'CONFIG_CONTROL_DESIGN.DERIVED_UNIT' IN TYPEOF(x) THEN
       REPEAT i := LOINDEX(x.elements) TO HIINDEX(x.elements) BY 1;
             result.length_exponent := result.length_exponent +
             (x.elements[i].
             exponent * x.elements[i].unit.dimensions.length_exponent);
             result.mass_exponent := result.mass_exponent + (x.elements[i].
             exponent * x.elements[i].unit.dimensions.mass_exponent);
             result.time_exponent := result.time_exponent + (x.elements[i].
             exponent * x.elements[i].unit.dimensions.time_exponent);
             result.electric_current_exponent := result.
             electric_current_exponent + (x.elements[i].exponent * x.
             elements[i].unit.dimensions.electric_current_exponent);
             result.thermodynamic_temperature_exponent := result.
             thermodynamic_temperature_exponent + (x.elements[i].exponent *
             x.elements[i].unit.dimensions.
             thermodynamic_temperature_exponent);
             result.amount_of_substance_exponent := result.
             amount_of_substance_exponent + (x.elements[i].exponent * x.
             elements[i].unit.dimensions.amount_of_substance_exponent);
             result.luminous_intensity_exponent := result.
             luminous_intensity_exponent + (x.elements[i].exponent * x.
             elements[i].unit.dimensions.luminous_intensity_exponent);
       END_REPEAT;
     ELSE
       result := x.dimensions;
     END_IF;
     RETURN(result);
   END_FUNCTION; -- derive_dimensional_exponents

the document 10303-203-aim-long.exp that the updated shtolo, libexpress,
libexppp create has function derive_dimensional_exponents as:

   FUNCTION derive_dimensional_exponents(
                x: unit
       ): dimensional_exponents;

     LOCAL
       i      : INTEGER;
       result : dimensional_exponents := dimensional_exponents(0,0,0,0,0,0,
                 0);
     END_LOCAL;
     result := x.dimensions;
     RETURN(result);

   END_FUNCTION; -- derive_dimensional_exponents

the reason for the difference is that the entity derived_unit is pruned.
both 10303-203-aim-long.exp (WG3 N916) and the newly created
10303-203-aim-long.exp prune entity derived_unit. which is correct.
once entity derived_unit is pruned any references to derived_unit should
also be pruned.

there are several other areas where WG3 N916 and the newly created
part203 express language files disagree. all deal with pruning.

>
> David
>

1. http://www.tc184-sc4.org/SC4_Open/SC4_Work_Products_Documents/STEP_(10303)/Files/ACF1D64.exp
2. http://www.tc184-sc4.org/SC4_Open/SC4_Work_Products_Documents/STEP_(10303)/Files/part501.exp
3. http://www.tc184-sc4.org/SC4_Open/SC4_Work_Products_Documents/STEP_(10303)/Files/part502.exp
4. http://www.tc184-sc4.org/SC4_Open/SC4_Work_Products_Documents/STEP_(10303)/Files/part510_is.exp
5. http://www.tc184-sc4.org/SC4_Open/SC4_Work_Products_Documents/STEP_(10303)/Files/part-511_is.exp
6. http://www.tc184-sc4.org/SC4_Open/SC4_Work_Products_Documents/STEP_(10303)/Files/part512.exp
7. http://www.tc184-sc4.org/SC4_Open/SC4_Work_Products_Documents/STEP_(10303)/Files/part514.exp

-- 
terry l. ridder ><>
From edbark at nist.gov  Wed Apr 20 13:41:55 2005
From: edbark at nist.gov (Ed Barkmeyer)
Date: Wed Apr 20 12:26:11 2005
Subject: [step-os] ap203 edition 1 question
In-Reply-To: <Pine.LNX.4.62.0504200850150.11068@johann.blauedonau.com>
References: <000a01c5458a$2fab5c50$2101a8c0@ESUKPC20>
	<Pine.LNX.4.62.0504200850150.11068@johann.blauedonau.com>
Message-ID: <42669463.7080800@nist.gov>

terry l. ridder wrote:

> 10303-203-aim-long.exp  is document WG3 N916
> 10303-203-aim-short.exp is document WG3 N915
...
> that being said. that document has errors.
> 
> specifically, function derive_dimensional_exponents is not pruned
> correctly.
> 
> document WG3 N916 has function derive_dimensional_exponents as:
> 
>   FUNCTION derive_dimensional_exponents(x: unit): dimensional_exponents;
>     LOCAL
>       i      : INTEGER;
>       result : dimensional_exponents := dimensional_exponents(0,0,0,0,0,0,
>                 0);
>     END_LOCAL;
>     IF 'CONFIG_CONTROL_DESIGN.DERIVED_UNIT' IN TYPEOF(x) THEN
>       REPEAT i := LOINDEX(x.elements) TO HIINDEX(x.elements) BY 1;
>             result.length_exponent := result.length_exponent +
>             (x.elements[i].
>             exponent * x.elements[i].unit.dimensions.length_exponent);
>             result.mass_exponent := result.mass_exponent + (x.elements[i].
>             exponent * x.elements[i].unit.dimensions.mass_exponent);
>             result.time_exponent := result.time_exponent + (x.elements[i].
>             exponent * x.elements[i].unit.dimensions.time_exponent);
>             result.electric_current_exponent := result.
>             electric_current_exponent + (x.elements[i].exponent * x.
>             elements[i].unit.dimensions.electric_current_exponent);
>             result.thermodynamic_temperature_exponent := result.
>             thermodynamic_temperature_exponent + (x.elements[i].exponent *
>             x.elements[i].unit.dimensions.
>             thermodynamic_temperature_exponent);
>             result.amount_of_substance_exponent := result.
>             amount_of_substance_exponent + (x.elements[i].exponent * x.
>             elements[i].unit.dimensions.amount_of_substance_exponent);
>             result.luminous_intensity_exponent := result.
>             luminous_intensity_exponent + (x.elements[i].exponent * x.
>             elements[i].unit.dimensions.luminous_intensity_exponent);
>       END_REPEAT;
>     ELSE
>       result := x.dimensions;
>     END_IF;
>     RETURN(result);
>   END_FUNCTION; -- derive_dimensional_exponents
> 
> the document 10303-203-aim-long.exp that the updated shtolo, libexpress,
> libexppp create has function derive_dimensional_exponents as:
> 
>   FUNCTION derive_dimensional_exponents(
>                x: unit
>       ): dimensional_exponents;
> 
>     LOCAL
>       i      : INTEGER;
>       result : dimensional_exponents := dimensional_exponents(0,0,0,0,0,0,
>                 0);
>     END_LOCAL;
>     result := x.dimensions;
>     RETURN(result);
> 
>   END_FUNCTION; -- derive_dimensional_exponents
> 
> the reason for the difference is that the entity derived_unit is pruned.
> both 10303-203-aim-long.exp (WG3 N916) and the newly created
> 10303-203-aim-long.exp prune entity derived_unit. which is correct.
> once entity derived_unit is pruned any references to derived_unit should
> also be pruned.
> 
> there are several other areas where WG3 N916 and the newly created
> part203 express language files disagree. all deal with pruning.

Two observations:
(1) "Pruning" the body of the function is an "optimization" -- in 
effect, it is simply less complicated code that produces the same 
result.  There is no statement in Part 11:2004, or Part 11:1994 with TC1 
and TC2, that would require, or even permit, the body of the FUNCTION to 
be altered.  It can only be included or excluded in the long form. 
Properly, the variation above can only possibly arise when there is a 
second definition of derive_dimensional_exponents (with the "pruned 
body") in one of the AIC schemas and the long-form definition is 
interfaced from there.

(2) The function derive_dimensional_exponents is not formally dependent 
on entity "derived_unit" being included in the interfacing schema (AP 
203 short form).  This is so because "derived_unit" is not the explicit 
data type, or a component of the data type, of any parameter or variable 
of the function.  Nor is it a supertype of any included entity.  Rather 
it is a subtype of "unit" that simply doesn't occur.
   The *string literal* 'CONFIG_CONTROL_DESIGN.DERIVED_UNIT' appears in 
the body of the function, but the interpretation of a string value 
depends on its use in the function, and in general, it is not possible 
for a parser to know that that string has some interface-related 
significance.  In practice, that value cannot be returned by the TypeOf 
call, but neither will 'DERIVED_UNIT' or 'HELLO' or schema_name + 
special_case[2], any of which is also a valid comparand.

-Ed

P.S. Representing model types and roles with data strings was a bad idea 
in 1987, a bad idea in 1994, and a bad idea in 2004.  But we are stuck 
with it.  This is just one of the many consequent annoyances.  As 
someone observed in my meeting earlier today: "In the land of the blind, 
the man with one eye is king."  That accounts for a lot of SC4-isms.

-- 
Edward J. Barkmeyer                        Email: edbark@nist.gov
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8264                Tel: +1 301-975-3528
Gaithersburg, MD 20899-8264                FAX: +1 301-975-4694

"The opinions expressed above do not reflect consensus of NIST,
  and have not been reviewed by any Government authority."

From terrylr at blauedonau.com  Wed Apr 20 15:00:09 2005
From: terrylr at blauedonau.com (terry l. ridder)
Date: Wed Apr 20 13:46:25 2005
Subject: [step-os] 10303-201-aim-long.exp 
Message-ID: <Pine.LNX.4.62.0504201206150.14826@johann.blauedonau.com>

hello;

note: 10303-201-aim-long.exp has no document id of any type.

using 10303-201-aim-long.exp from either steptools archives or from
tc184-sc4.org it is obvious that it has errors.

in functions derive_dimensional_exponents and valid_units any 'MEASURE_SCHEMA.'
is clearly incorrect. they should be 'EXPLICIT_DRAUGHTING.'.

an additional problem with function derive_dimensional_exponents is the
same problem that 10303-203-aim-long.exp (wg3 n916) has.


   FUNCTION derive_dimensional_exponents (x : unit) : dimensional_exponents;
     LOCAL
       i      : INTEGER;
       result : dimensional_exponents :=
                dimensional_exponents(0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0);
     END_LOCAL;
     IF 'MEASURE_SCHEMA.DERIVED_UNIT' IN TYPEOF(x) THEN -- x is a derived unit
       REPEAT i := LOINDEX(x.elements) TO HIINDEX(x.elements);
         result.length_exponent                    :=
           result.length_exponent +
           (x.elements[i].exponent *
            x.elements[i].unit.dimensions.length_exponent);
         result.mass_exponent                      :=
           result.mass_exponent +
           (x.elements[i].exponent *
            x.elements[i].unit.dimensions.mass_exponent);
        result.time_exponent :=
           result.time_exponent +
           (x.elements[i].exponent *
            x.elements[i].unit.dimensions.time_exponent);
         result.electric_current_exponent          :=
           result.electric_current_exponent +
           (x.elements[i].exponent *
            x.elements[i].unit.dimensions.electric_current_exponent);
         result.thermodynamic_temperature_exponent :=
           result.thermodynamic_temperature_exponent +
           (x.elements[i].exponent *
            x.elements[i].unit.dimensions.thermodynamic_temperature_exponent);
         result.amount_of_substance_exponent       :=
           result.amount_of_substance_exponent +
           (x.elements[i].exponent *
            x.elements[i].unit.dimensions.amount_of_substance_exponent);
         result.luminous_intensity_exponent        :=
           result.luminous_intensity_exponent +
           (x.elements[i].exponent *
            x.elements[i].unit.dimensions.luminous_intensity_exponent);
       END_REPEAT;
     ELSE -- x is a unitless or a named unit
       result := x.dimensions;
     END_IF;
     RETURN (result);
   END_FUNCTION;

   FUNCTION valid_units ( m : measure_with_unit ) : BOOLEAN ;
     IF 'MEASURE_SCHEMA.LENGTH_MEASURE' IN TYPEOF ( m.value_component ) THEN
       IF derive_dimensional_exponents ( m.unit_component ) <>
          dimensional_exponents ( 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0 ) THEN
         RETURN (FALSE);
       END_IF;
     END_IF;
     IF 'MEASURE_SCHEMA.MASS_MEASURE' IN TYPEOF ( m.value_component ) THEN
       IF derive_dimensional_exponents ( m.unit_component ) <>
          dimensional_exponents ( 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0 ) THEN
         RETURN (FALSE);
       END_IF;
     END_IF;
     IF 'MEASURE_SCHEMA.TIME_MEASURE' IN TYPEOF ( m.value_component ) THEN
       IF derive_dimensional_exponents ( m.unit_component ) <>
          dimensional_exponents ( 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0 ) THEN
         RETURN (FALSE);
       END_IF;
     END_IF;
    IF 'MEASURE_SCHEMA.ELECTRIC_CURRENT_MEASURE' IN TYPEOF ( m.value_component ) THEN
       IF derive_dimensional_exponents ( m.unit_component ) <>
          dimensional_exponents ( 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0 ) THEN
         RETURN (FALSE);
       END_IF;
     END_IF;
     IF 'MEASURE_SCHEMA.THERMODYNAMIC_TEMPERATURE_MEASURE'
     IN TYPEOF ( m.value_component ) THEN
       IF derive_dimensional_exponents ( m.unit_component ) <>
          dimensional_exponents ( 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0 ) THEN
         RETURN (FALSE);
       END_IF;
     END_IF;
     IF 'MEASURE_SCHEMA.AMOUNT_OF_SUBSTANCE_MEASURE' IN TYPEOF ( m.value_component ) THEN
       IF derive_dimensional_exponents ( m.unit_component ) <>
          dimensional_exponents ( 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0 ) THEN
         RETURN (FALSE);
       END_IF;
     END_IF;
     IF 'MEASURE_SCHEMA.LUMINOUS_INTENSITY_MEASURE' IN TYPEOF ( m.value_component ) THEN
       IF derive_dimensional_exponents ( m.unit_component ) <>
          dimensional_exponents ( 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0 ) THEN
         RETURN (FALSE);
       END_IF;
     END_IF;
     IF 'MEASURE_SCHEMA.PLANE_ANGLE_MEASURE' IN TYPEOF ( m.value_component ) THEN
       IF derive_dimensional_exponents ( m.unit_component ) <>
          dimensional_exponents ( 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0 ) THEN
         RETURN (FALSE);
       END_IF;
     END_IF;
     IF 'MEASURE_SCHEMA.SOLID_ANGLE_MEASURE' IN TYPEOF ( m.value_component ) THEN
       IF derive_dimensional_exponents ( m.unit_component ) <>
          dimensional_exponents ( 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0 ) THEN
         RETURN (FALSE);
       END_IF;
     END_IF;
     IF 'MEASURE_SCHEMA.AREA_MEASURE' IN TYPEOF ( m.value_component ) THEN
       IF derive_dimensional_exponents ( m.unit_component ) <>
          dimensional_exponents ( 2.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0 ) THEN
         RETURN (FALSE);
       END_IF;
     END_IF;
     IF 'MEASURE_SCHEMA.VOLUME_MEASURE' IN TYPEOF ( m.value_component ) THEN
       IF derive_dimensional_exponents ( m.unit_component ) <>
          dimensional_exponents ( 3.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0 ) THEN
         RETURN (FALSE);
       END_IF;
     END_IF;
     IF 'MEASURE_SCHEMA.RATIO_MEASURE' IN TYPEOF ( m.value_component ) THEN
       IF derive_dimensional_exponents ( m.unit_component ) <>
          dimensional_exponents ( 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0 ) THEN
         RETURN (FALSE);
       END_IF;
     END_IF;
     IF 'MEASURE_SCHEMA.POSITIVE_LENGTH_MEASURE' IN TYPEOF ( m.value_component ) THEN
       IF derive_dimensional_exponents ( m.unit_component ) <>
          dimensional_exponents ( 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0 ) THEN
         RETURN (FALSE);
       END_IF;
     END_IF;
     IF 'MEASURE_SCHEMA.POSITIVE_PLANE_ANGLE_MEASURE' IN TYPEOF ( m.value_component ) THEN
       IF derive_dimensional_exponents ( m.unit_component ) <>
          dimensional_exponents ( 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0 ) THEN
         RETURN (FALSE);
       END_IF;
     END_IF;
     RETURN (TRUE);
   END_FUNCTION;


also any mention of the below should have been pruned.

EXPLICIT_DRAUGHTING.AMOUNT_OF_SUBSTANCE_MEASURE
EXPLICIT_DRAUGHTING.ANNOTATION_TEXT_CHARACTER
EXPLICIT_DRAUGHTING.AREA_MEASURE
EXPLICIT_DRAUGHTING.DEFINED_CHARACTER_GLYPH
EXPLICIT_DRAUGHTING.DERIVED_UNIT
EXPLICIT_DRAUGHTING.ELECTRIC_CURRENT_MEASURE
EXPLICIT_DRAUGHTING.EXTERNALLY_DEFINED_STYLE
EXPLICIT_DRAUGHTING.ITEM_DEFINED_TRANSFORMATION
EXPLICIT_DRAUGHTING.LUMINOUS_INTENSITY_MEASURE
EXPLICIT_DRAUGHTING.MAPPING_SOURCE
EXPLICIT_DRAUGHTING.MASS_MEASURE
EXPLICIT_DRAUGHTING.POSITIVE_PLANE_ANGLE_MEASURE
EXPLICIT_DRAUGHTING.SOLID_ANGLE_MEASURE
EXPLICIT_DRAUGHTING.SURFACE
EXPLICIT_DRAUGHTING.SURFACE_STYLE_USAGE
EXPLICIT_DRAUGHTING.TEXT_STRING_REPRESENTATION
EXPLICIT_DRAUGHTING.THERMODYNAMIC_TEMPERATURE_MEASURE
EXPLICIT_DRAUGHTING.TIME_MEASURE
EXPLICIT_DRAUGHTING.VOLUME_MEASURE

none of the above are declared in 10303-201-aim-long.exp as
either TYPE, ENTITY, FUNCTION, or RULE.

other examples are functions acyclic_mapped_representation,
item_in_context, and using_representations.
the 'REPRESENTATION_SCHEMA.' should be 'EXPLICIT_DARUAGHTING.'.

   FUNCTION acyclic_mapped_representation
     (parent_set   : SET OF representation;
      children_set : SET OF representation_item) : BOOLEAN;
     LOCAL
       x,y : SET OF representation_item;
       i   : INTEGER;
     END_LOCAL;
     x := QUERY(z <* children_set | 'REPRESENTATION_SCHEMA.MAPPED_ITEM'
          IN TYPEOF(z));
     IF SIZEOF(x) > 0 THEN
       REPEAT i := 1 TO HIINDEX(x);
         IF x[i]\mapped_item.mapping_source.mapped_representation
           IN parent_set THEN
           RETURN (FALSE);
         END_IF;
         IF NOT acyclic_mapped_representation
           (parent_set + x[i]\mapped_item.mapping_source.mapped_representation,
           x[i]\mapped_item.mapping_source.mapped_representation.items) THEN
           RETURN (FALSE);
         END_IF;
       END_REPEAT;
     END_IF;
     x := children_set - x;
     IF SIZEOF(x) > 0 THEN
       REPEAT i := 1 TO HIINDEX(x);
         y := QUERY(z <* bag_to_set( USEDIN(x[i], '')) |
              'REPRESENTATION_SCHEMA.REPRESENTATION_ITEM' IN TYPEOF(z));
           IF NOT acyclic_mapped_representation(parent_set, y) THEN
           RETURN (FALSE);
         END_IF;
       END_REPEAT;
     END_IF;
     RETURN (TRUE);
   END_FUNCTION;

   FUNCTION item_in_context
     (item  : representation_item;
      cntxt : representation_context) : BOOLEAN;
     LOCAL
       i : INTEGER;
       y : BAG OF representation_item;
     END_LOCAL;
     IF SIZEOF(USEDIN(item,'REPRESENTATION_SCHEMA.REPRESENTATION.ITEMS')
       * cntxt.representations_in_context) > 0 THEN
       RETURN (TRUE);
       ELSE
       y := QUERY(z <* USEDIN (item , '') |
            'REPRESENTATION_SCHEMA.REPRESENTATION_ITEM' IN TYPEOF(z));
         IF SIZEOF(y) > 0 THEN
         REPEAT i := 1 TO HIINDEX(y);
           IF item_in_context(y[i], cntxt) THEN
             RETURN (TRUE);
           END_IF;
         END_REPEAT;
       END_IF;
     END_IF;
     RETURN (FALSE);
   END_FUNCTION;

   FUNCTION using_representations (item : representation_item)
     : SET OF representation;
     LOCAL
       results            : SET OF representation;
       result_bag         : BAG OF representation;
       intermediate_items : SET OF representation_item;
       i                  : INTEGER;
     END_LOCAL;
     result_bag := USEDIN(item,'REPRESENTATION_SCHEMA.REPRESENTATION.ITEMS');
     IF SIZEOF(result_bag) > 0 THEN
       REPEAT i := 1 TO HIINDEX(result_bag);
         results := results + result_bag[i];
       END_REPEAT;
     END_IF;
     intermediate_items := QUERY(z <* bag_to_set( USEDIN(item , '')) |
       'REPRESENTATION_SCHEMA.REPRESENTATION_ITEM' IN TYPEOF(z));
     IF SIZEOF(intermediate_items) > 0 THEN
       REPEAT i := 1 TO HIINDEX(intermediate_items);
         results := results + using_representations(intermediate_items[i]);
       END_REPEAT;
     END_IF;
     RETURN (results);
   END_FUNCTION;


further examples.
the 'GEOMETRY_SCHEMA.' should be 'EXPLICIT_DARUAGHTING.'.

    FUNCTION normalise (arg : vector_or_direction) : vector_or_direction;
      LOCAL
        ndim   : INTEGER;
        v      : direction;
        result : vector_or_direction;
        vec    : vector;
        mag    : REAL;
      END_LOCAL;
      IF NOT EXISTS (arg) THEN
        result := ?;
      ELSE
        ndim := arg.dim;
        IF 'GEOMETRY_SCHEMA.VECTOR' IN TYPEOF(arg) THEN
          BEGIN
            vec := arg;
            v := arg.orientation;
            IF arg.magnitude = 0.0 THEN
              RETURN(?);
            ELSE
              vec.magnitude := 1.0;
            END_IF;
          END;
        ELSE
          v := arg;
        END_IF;
        mag := 0.0;
        REPEAT  i := 1 TO ndim;
          mag := mag + v.direction_ratios[i]*v.direction_ratios[i];
        END_REPEAT;
        IF mag > 0.0 THEN
          mag := SQRT(mag);
          REPEAT  i := 1 TO ndim;
            v.direction_ratios[i] := v.direction_ratios[i]/mag;
          END_REPEAT;
          IF 'GEOMETRY_SCHEMA.VECTOR' IN TYPEOF(arg) THEN
            vec.orientation := v;
            result := vec;
          ELSE
            result := v;
          END_IF;
        ELSE
          RETURN(?);
        END_IF;
      END_IF;
      RETURN (result);
    END_FUNCTION;

the 'PRESENTATION_DEFINITION_SCHEMA.' should be 'EXPLICIT_DARUAGHTING.'.

   FUNCTION acyclic_composite_text(start_composite : composite_text;
                                   child_text : SET [1:?] OF
                                   text_or_character) : LOGICAL;
     LOCAL
      i : INTEGER;
      local_composite_text : SET [0:?] OF composite_text;
      local_annotation_text : SET [0:?] OF annotation_text;
      local_children : SET [0:?] OF text_or_character;
     END_LOCAL;
     local_composite_text := QUERY (child <* child_text |
                             ('PRESENTATION_DEFINITION_SCHEMA.COMPOSITE_TEXT'
                              IN TYPEOF (child)));
     IF (SIZEOF (local_composite_text) > 0) THEN
       REPEAT i := 1 TO HIINDEX (local_composite_text);
         IF (start_composite :=: local_composite_text[i]) THEN
           RETURN (FALSE);
         END_IF;
       END_REPEAT;
     END_IF;
     local_children := child_text;
     IF (SIZEOF (local_composite_text)) > 0 THEN
       REPEAT i := 1 TO HIINDEX (local_composite_text);
         local_children := local_children +
                           local_composite_text[i].collected_text;
       END_REPEAT;
     END_IF;
     local_annotation_text := QUERY (child <* child_text |
                             ('PRESENTATION_DEFINITION_SCHEMA.ANNOTATION_TEXT'
                              IN TYPEOF (child)));
     IF (SIZEOF (local_annotation_text) > 0) THEN
       REPEAT i := 1 TO HIINDEX (local_annotation_text);
         local_children := local_children +
         QUERY (item <* local_annotation_text[i]\mapped_item.
                        mapping_source.mapped_representation.items |
           SIZEOF(['PRESENTATION_DEFINITION_SCHEMA.ANNOTATION_TEXT',
                   'PRESENTATION_DEFINITION_SCHEMA.COMPOSITE_TEXT'] *
                   TYPEOF(item)) > 0);
       END_REPEAT;
     END_IF;
     IF (local_children :<>: child_text) THEN
       RETURN (acyclic_composite_text (start_composite, local_children));
     ELSE
       RETURN (TRUE);
     END_IF;
    END_FUNCTION;



-- 
terry l. ridder ><>
From lothar.klein at lksoft.com  Wed Apr 20 15:29:21 2005
From: lothar.klein at lksoft.com (Lothar Klein)
Date: Wed Apr 20 14:13:46 2005
Subject: [step-os] 10303-201-aim-long.exp
In-Reply-To: <Pine.LNX.4.62.0504201206150.14826@johann.blauedonau.com>
References: <Pine.LNX.4.62.0504201206150.14826@johann.blauedonau.com>
Message-ID: <1025478150.20050420212921@lksoft.com>

Terry,

What you say is no a surprise.
AP201 together with AP203 were first APs to release.
Afterwards many errors in the IRs have been fixed,
but AP201 got never a technical corrigendum.
Meanwhile it is now time to create a 2nd edition of AP201 within
stepmod. Do you want to participate?

Lothar

-- 
// Lothar Klein, LKSoftWare GmbH
// Steinweg 1, 36093 Kuenzell, Germany
// +49 661 933933-0, Fax: -2
// mailto:lothar.klein@lksoft.com   http://www.lksoft.com

Wednesday, April 20, 2005, 9:00:09 PM, you wrote:
> hello;

> note: 10303-201-aim-long.exp has no document id of any type.

> using 10303-201-aim-long.exp from either steptools archives or from
> tc184-sc4.org it is obvious that it has errors.

...

From terrylr at blauedonau.com  Wed Apr 20 16:12:37 2005
From: terrylr at blauedonau.com (terry l. ridder)
Date: Wed Apr 20 14:58:52 2005
Subject: [step-os] 10303-201-aim-long.exp
In-Reply-To: <1025478150.20050420212921@lksoft.com>
References: <Pine.LNX.4.62.0504201206150.14826@johann.blauedonau.com>
	<1025478150.20050420212921@lksoft.com>
Message-ID: <Pine.LNX.4.62.0504201502390.17194@johann.blauedonau.com>

hello;

lothar, i need to whitelist you in my mail servers. may take a couple
days for me to get to it.

reply intermixed below.

On Wed, 20 Apr 2005, Lothar Klein wrote:

> Terry,
>
> What you say is no a surprise.
>

that is sad.

>
> AP201 together with AP203 were first APs to release.
> Afterwards many errors in the IRs have been fixed,
> but AP201 got never a technical corrigendum.
>

i noticed that 10303-201 does not appear to have a short form.
i did find what appears to be the short form riddled with latex in
express comments '(*/*)'.

>
> Meanwhile it is now time to create a 2nd edition of AP201 within
> stepmod. Do you want to participate?
>

i assume you are referring to stepmod.sourceforge.net project.
i have looked at the project briefly.
a part of stepmod uses osexpress, which is written in java.
i do not do java.

that depends on the definition of 'participate'.

>
> Lothar
>
>

-- 
terry l. ridder ><>
From terrylr at blauedonau.com  Thu Apr 21 14:58:44 2005
From: terrylr at blauedonau.com (terry l. ridder)
Date: Thu Apr 21 13:45:05 2005
Subject: [step-os] ap203 edition 1 question
In-Reply-To: <42669463.7080800@nist.gov>
References: <000a01c5458a$2fab5c50$2101a8c0@ESUKPC20>
	<Pine.LNX.4.62.0504200850150.11068@johann.blauedonau.com>
	<42669463.7080800@nist.gov>
Message-ID: <Pine.LNX.4.62.0504210743240.20868@johann.blauedonau.com>

hello;

reply intermixed below.

i am quoting from WG11-N246 10303-11ed2.pdf.
i do not have a copy of 10303-11 edition 1.

On Wed, 20 Apr 2005, Ed Barkmeyer wrote:

<snip>
>
> Two observations:
> (1) "Pruning" the body of the function is an "optimization" -- in effect, it 
> is simply less complicated code that produces the same result.  There is no 
> statement in Part 11:2004, or Part 11:1994 with TC1 and TC2, that would 
> require, or even permit, the body of the FUNCTION to be altered.  It can only 
> be included or excluded in the long form. Properly, the variation above can 
> only possibly arise when there is a second definition of 
> derive_dimensional_exponents (with the "pruned body") in one of the AIC 
> schemas and the long-form definition is interfaced from there.
>

function derive_dimensional_exponents is declared in ir 10303-41
(wg12-n304, wn12-n525, and wg12-n2887), in schema measure_schema.

function derived_dimensional_exponents is basically identical in
wg12-n304, wg12-n525, and wg12-n2887.

i find no alter declaration of the function derive_dimensional_exponents
any where else.

i do find that steptools also 'optimized' function
derive_dimensional_exponents.

function derive_dimensional_exponents in ap203 
http://www.steptools.com/support/stdev_docs/express/part203/t_deriv-01.html

function derive_dimensional_exponents in part41
http://www.steptools.com/support/stdev_docs/express/part41/t_deriv-03.html

for a library or program to support any application protocol parts which
include function derive_dimensional_exponents and similar functions, is
verbatium implementation required or is 'form, fit, and function' allowed?

>
> (2) The function derive_dimensional_exponents is not formally dependent on 
> entity "derived_unit" being included in the interfacing schema (AP 203 short 
> form).  This is so because "derived_unit" is not the explicit data type, or a 
> component of the data type, of any parameter or variable of the function. 
> Nor is it a supertype of any included entity.  Rather it is a subtype of 
> "unit" that simply doesn't occur.
>

as quoted below from annex g, once the longform is created, knowledge of
the schema from which each construct orginates is lost. given that
'derived_unit' is 'pruned' any attempt at validating the longform with
a program like 'fedex' will result in errors. fedex, has no declaration
of 'derived_unit' to compare any reference to 'derived_unit' with.
fedex, will complain of errors in the longform input file.

while validating any longform schema with a program like 'fedex' does
not guarantee that the schema makes any useful sense, it does catch
express language errors.

>
>  The *string literal* 'CONFIG_CONTROL_DESIGN.DERIVED_UNIT' appears in the 
> body of the function, but the interpretation of a string value depends on its 
> use in the function, and in general, it is not possible for a parser to know 
> that that string has some interface-related significance.  In practice, that 
> value cannot be returned by the TypeOf call, but neither will 'DERIVED_UNIT' 
> or 'HELLO' or schema_name + special_case[2], any of which is also a valid 
> comparand.
>

i respectful disagree with the above.

given 10303-11 clause 11, interface specification, clause 15.25 TypeOf
- general function, and annex g, generating a single schema from multiple
schemas.

clause 15.25, clearly states:

<begin quote>

...

Result : The contents of the returned set of string values are the
names (in upper case) of all types that the value V is a member of.
Such names are qualified by the name of the schema that contains the
definition of the type ('SCHEMA.TYPE') if it is neither a simple data
type nor an aggregation data type. It may be derived by the following
algorithm (which is given here for specification purposes rather than
to prescribe any particular type of implementation):

...

<end   quote>

clause 15.25 also states:

<begin quote>

...

4) Repeat for all names in the result set:
    -- if the current name has been brought into its schema by means of
       reference or use: the name in the interfaced schema qualified by
       the name of the interfaced schema is added to the result set.
       Since use statements may be chained, the name in all chained
       schemas qualified by the schema names are also added to the
       set.

...

<end   quote>

clause 15.25, also gives the following 2 examples:

<begin quote>

...

EXAMPLE 1        In the context of the following schema
SCHEMA this_schema;
   TYPE
      mylist = LIST [1 : 20] OF REAL;
   END_TYPE;
   ...
   LOCAL
      lst : mylist;
   END_LOCAL;
   ...
END_SCHEMA;

the following conditions are true:

TYPEOF (lst)      = ['THIS_SCHEMA.MYLIST', 'LIST']
TYPEOF (lst [17]) = ['REAL', 'NUMBER']

EXAMPLE 2        The effects of use or reference are shown based on the
previous example:

SCHEMA another_schema;
   REFERENCE FROM this_schema (mylist AS hislist);
   ...
      lst : hislist;
   ...
END_SCHEMA;

In this context, the following statement is true:

TYPEOF (lst) = ['ANOTHER_SCHEMA.HISLIST', 'THIS_SCHEMA.MYLIST', 'LIST']

...

<end   quote>

the above clearly shows that the parser must retain knowledge of where a
construct orginates from. this is true even if the contruct is 'pruned'
as per annex g.

annex g, states the following:

<begin quote>
There are two stages to the conversion process, each of which involves
semantic losses:

a) The multi-schema data specification is converted to an intermediate
single schema specification. The following major transformations are
applied:


-- Selectable items of a select type are pruned to remove those items
    that are not interfaced into the schema. According to 11.4.2,
    selectable items are not implicitly interfaced as a result of the
    interfacing of the select type itself.  If the selectable items were
    left in the select list, and the ob jects were not visible in the
    schema, the compilation of the longform schema would result in errors.

-- subtype constraint's are pruned to reflect the pruning of the
    subtype/supertype graph as described in 11.4.3 and annex C.

-- rule's are pruned to reflect the pruning of the subtype/supertype
    graph as described in 11.4.3 and annex C.

-- schema names in fully qualified attribute references are replaced
    with the schema name of the longform.

-- The knowledge of how the constructs were interfaced, that is, their
    visibility and instantiability, are transformed into rules.
    Information describing how the object was interfaced (the distinction
    between use and reference), affects its instantiability and visibility;
    see clause 11 paragraphs 2 and 3.

The following semantic information may be lost:

-- Loss of knowledge of the schema that each construct originates from.

-- Remarks that do not have remark tags (see 7.1.6.3) may be discarded.

-- The case of user identifiers may not be preserved.
<end   quote>

given the above, the parser must have knowledge of which 'string literal'
have interface-related significance, since they must be renamed with the
schema name of the longform. given that the parser is able to
'optimized' a function declaration. the 'optimization' allows fedex to
validate the longform schema and removes code that is extraneous.

>
> -Ed
>
> P.S. Representing model types and roles with data strings was a bad idea in 
> 1987, a bad idea in 1994, and a bad idea in 2004.  But we are stuck with it. 
> This is just one of the many consequent annoyances.  As someone observed in 
> my meeting earlier today: "In the land of the blind, the man with one eye is 
> king."  That accounts for a lot of SC4-isms.
>
>

to rephrase the above:

"it is broken, we know it is broken, but we are not going to fix it"

why not correct the mistakes of the past instead is carrying them
foward?

-- 
terry l. ridder ><>
From edbark at nist.gov  Thu Apr 21 19:03:26 2005
From: edbark at nist.gov (Ed Barkmeyer)
Date: Thu Apr 21 17:47:12 2005
Subject: [step-os] ap203 edition 1 question
In-Reply-To: <Pine.LNX.4.62.0504210743240.20868@johann.blauedonau.com>
References: <000a01c5458a$2fab5c50$2101a8c0@ESUKPC20>
	<Pine.LNX.4.62.0504200850150.11068@johann.blauedonau.com>
	<42669463.7080800@nist.gov>
	<Pine.LNX.4.62.0504210743240.20868@johann.blauedonau.com>
Message-ID: <4268313E.8060503@nist.gov>

I wrote:

>> (2) The function derive_dimensional_exponents is not formally 
>> dependent on entity "derived_unit" being included in the interfacing 
>> schema (AP 203 short form).  This is so because "derived_unit" is not 
>> the explicit data type, or a component of the data type, of any 
>> parameter or variable of the function. Nor is it a supertype of any 
>> included entity.  Rather it is a subtype of "unit" that simply doesn't 
>> occur.

terry l. ridder wrote:

> as quoted below from annex g, once the longform is created, knowledge of
> the schema from which each construct orginates is lost. given that
> 'derived_unit' is 'pruned' any attempt at validating the longform with
> a program like 'fedex' will result in errors. fedex, has no declaration
> of 'derived_unit' to compare any reference to 'derived_unit' with.
> fedex, will complain of errors in the longform input file.

If the compiler says this is an "error", as distinct from a "warning", 
it is being overzealous, and it does not conform to any edition of Part 
11.

There is absolutely nothing wrong with the EXPRESS FUNCTION definition 
you quoted.  The value 'CONFIGURATION_CONTROLLED_DESIGN.DERIVED_UNIT' is 
a valid string literal being tested for membership in a SET OF STRING. 
The fact that that test always fails is interesting, but it is neither 
syntactically nor semantically an invalid expression.  You interpret 
that string literal as a reference to an undefined data type, but the 
EXPRESS compiler is not required to -- syntactically and semantically, 
that is a string literal, full stop.  It is only a reference to some 
data type if it is provided to a function that so interprets it, and 
that is not the case here.

I would readily believe that a smart compiler could issue a warning that 
the test will always fail.  That is a very different thing from saying 
the EXPRESS is invalid.

>>  The *string literal* 'CONFIG_CONTROL_DESIGN.DERIVED_UNIT' appears in 
>> the body of the function, but the interpretation of a string value 
>> depends on its use in the function, and in general, it is not possible 
>> for a parser to know that that string has some interface-related 
>> significance.  In practice, that value cannot be returned by the 
>> TypeOf call, but neither will 'DERIVED_UNIT' or 'HELLO' or schema_name 
>> + special_case[2], any of which is also a valid comparand.
>>
> 
> i respectful disagree with the above.

You are welcome to do so.  I respectfully suggest you put this issue to 
wg11@steptools.com, which is the exploder for the ISO group that 
maintains the standard.  I am the remaining U.S. technical expert on 
Part 11, so far as I know.  But that way you should get the benefit of a 
hearing by the Japanese, German, Norweigian and British experts who also 
developed the standard.

> given 10303-11 clause 11, interface specification, clause 15.25 TypeOf
> - general function, and annex g, generating a single schema from multiple
> schemas.
> 
> clause 15.25, clearly states: ...

All of the quoted material explains exactly what TypeOf produces.
But the issue here is not what TypeOf produces, because it will never 
produce '...DERIVED_UNIT'.  The validity issue is what string literals 
may be compared with the output of a function that produces a SET OF 
STRING.  That is described in Clause 12.

> the above clearly shows that the parser must retain knowledge of where a
> construct orginates from. this is true even if the contruct is 'pruned'
> as per annex g.

Of course the parser must, and that is more carefully described in 
Clause 11 (Interfacing), which defines "pruning".

> annex g, states the following:
> ...
> -- schema names in fully qualified attribute references are replaced
>    with the schema name of the longform.
> ...
> 
> given the above, the parser must have knowledge of which 'string literal'
> have interface-related significance, since they must be renamed with the
> schema name of the longform. 

Be very careful here.  Annex G is a specification for a tool that 
converts a short-form EXPRESS schema to a long-form EXPRESS schema that 
is said to be (but isn't quite) equivalent.  The Annex G specification 
has nothing to do with the validity of the EXPRESS text or the 
conformance of an EXPRESS parser.  The set of rules presumably generates 
valid EXPRESS long-forms from valid EXPRESS short-forms, but that's all.

And you will note that what is required is that, in any string that 
contains a literal schema name, the schema name part is replaced with 
the longform schema name, full stop.  It says nothing whatever about 
examining or evaluating anything after the first dot.

[There is an error in the text Terry quotes from Annex G.  The quoted 
text of Annex G should say "fully qualified data type and attribute 
references".  But in fact, it is not in general possible to know that 
that is what the string really is, and what properly occurs is the 
substitution of the longform schema name for any occurrence of an 
interfaced schema name in a literal.]

> given that the parser is able to
> 'optimized' a function declaration. the 'optimization' allows fedex to
> validate the longform schema and removes code that is extraneous.

That may be, but there is no specification in Annex G that requires such 
optimization, at least not that I can find.  It may indeed be permitted.
I took issue with your statements about "errors" and "required pruning" 
that are simply not supported by Part 11.

I also wrote:
>> P.S. Representing model types and roles with data strings was a bad 
>> idea in 1987, a bad idea in 1994, and a bad idea in 2004.  But we are 
>> stuck with it. This is just one of the many consequent annoyances.  As 
>> someone observed in my meeting earlier today: "In the land of the 
>> blind, the man with one eye is king."  That accounts for a lot of 
>> SC4-isms.

And Terry says:
> to rephrase the above:
> 
> "it is broken, we know it is broken, but we are not going to fix it"
> 
> why not correct the mistakes of the past instead is carrying them
> foward?

I will grant you that Annex G might be improved to require the kind of 
"pruning" of FUNCTION text you want.  And it will have very little 
impact, because the results are 100% equivalent to the current ones.

But trying to repair a 20-year-old design error in the EXPRESS language 
is quite another thing entirely.  How many thousand lines of ISO 
standards would you be willing to modify, using the ISO consensus 
process, in order to correct this aspect of the design of the EXPRESS 
language?

In the same vein, why not throw away the ill-designed hack that is 
Windows and design a real operating system based on 30 years of 
knowledge of how to do it right, and in so doing, triple the speed, cut 
the memory size in half, fix most of the ActiveX problems, and greatly 
simplify system management?  Because all the application software would 
stop working!  Why don't you have a Dworak typewriter keyboard instead 
of the anti-ergonomic QWERTY keyboard?  Because there is too much 
committed investment!

There are some projects in which a poor initial design will doom the 
project, and there are others in which the poor initial design 
regrettably doesn't, and entire social and technical generations suffer. 
  The IBM PC is a wonderful awful example of the latter.  By comparison, 
the SC4 mistakes are but a gnat in your soup.

-Ed

-- 
Edward J. Barkmeyer                        Email: edbark@nist.gov
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8264                Tel: +1 301-975-3528
Gaithersburg, MD 20899-8264                FAX: +1 301-975-4694

"The opinions expressed above do not reflect consensus of NIST,
  and have not been reviewed by any Government authority."