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: 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: 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: <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: <000a01c5458a$2fab5c50$2101a8c0@ESUKPC20> <1133209874.20050420115454@lksoft.com> Message-ID: 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: 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: References: <000a01c5458a$2fab5c50$2101a8c0@ESUKPC20> 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: 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: References: 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: <1025478150.20050420212921@lksoft.com> Message-ID: 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> <42669463.7080800@nist.gov> Message-ID: 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: > > 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: ... 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): ... clause 15.25 also states: ... 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. ... clause 15.25, also gives the following 2 examples: ... 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'] ... 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: 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. 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: References: <000a01c5458a$2fab5c50$2101a8c0@ESUKPC20> <42669463.7080800@nist.gov> 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."