[step-manufacturing] Specification of the AP Binding

Martin Hardwick hardwick at steptools.com
Fri Jul 16 13:51:28 EDT 2004


All,

As per the mandate given to T24 at the SC4 meeting here is
a specification for the AP binding. All and any suggestions
for improvements are welcomed, particularly when they correct
errors and ambiguities. 

However, when making suggestions please remember that speed
is an important goal for this project. We want to have a CD
draft ready for the next SC4 meeting. There are many areas 
where additional flexibility can be added without much cost
but in most cases it may be best to add these via the ballot
comment/resolution process.

One of the items for discussion in the teleconference should
be whether this binding can be completed most efficiently by
writing a conformance class of P28 or by writing a new document
using the existing P21 as a model.

Martin Hardwick
Team Leader T24 STEP-Manufacturing

+++++++++++++++++++++++++++++++++++++++
AP Binding Requirements

1. The AP binding needs to follow the mainstream conventions for XML data 
   (no surprises to the end user). 
2. The AP binding must have sufficient legibility/understandability to 
   allow the AP developers to add definitions to the schema that may come from 
   the AAM, ARM, mapping tables and AIM rules. 
3. The AP binding specification must be clear, concise and precise to support
   easy conformance checking by vendors and end users. 
4. The AP binding must be implementable by those who have developed
   P21 parsers without requiring them to purchase or otherwise obtain 
   additional tooling for any reason including pre-processing or 
   post-processing data described by a configuration.
5. The AP binding must allow AP implementations to inter-operate when
   those AP's contain harmonized AIM definitions.

+++++++++++++++++++++++++++++++++++++++
Specification of the AP Binding

1. Case conventions

   Entity names converted to upper case. Attribute 
   names converted to lower case. Type names 
   converted to upper case. 

2. Handling of entities

   Entity is tagged with its name and an id.

   Each attribute is tagged with its name.

   Each attribute describe by an entity value 
   has either an href attribute to the entity
   or the value is described in place using nesting.

   AP developers can choose to define only one 
   form (href or nesting) in their XML Schema for 
   a given attribute and then state that the other 
   form may also be used.  

   Nested instances may be referenced by other instances.

   <PRODUCT_DEFINITION id="pd45" > 
       <id>PR-3456-Manufacturing</id> 
       <formation href="#pdf78" /> 
   </PRODUCT_DEFINITION> 

   <PRODUCT_DEFINITION_FORMATION id="pdf78" > 
        <id>PR23-67-PDF</id> 
        <of_product> 
           <PRODUCT id="p078"> 
              <id>PR2345-76A</id> 
              <name>machining project</name> 
           </PRODUCT> 
        </of_product> 
   </PRODUCT_DEFINITION_FORMATION>

3. Handling of selects

   Primitive types are always tagged with the most 
   specific type name.

   Entity types are tagged with the name of the type
   If a path of nested selects is necessary then the 
   XML tag contains an attribute called path which contains 
   a white space delimited list of type names as per the 
   Part 21 specification.

   <CIRCLE id="c56" > 
       <position href="#a2p-102" /> <!-- this is a select -->
   </CIRCLE>

   <AXIS2_PLACEMENT_3D id="a2p-102"> 
    ... 
   </AXIS2_PLACEMENT_3D> 

   In the following EXPRESS (from P21) 

   TYPE Mass = SELECT(Mass_Spec, Mass_Substitute); 
   END_TYPE;

   TYPE Mass_Spec = SELECT(Measured_Mass, Computed_Mass, Estimated_Mass); 
   END_TYPE;

   TYPE Measured_Mass = REAL; 
   END_TYPE;

   TYPE Computed_Mass = Extended_Real; 
   END_TYPE;

   TYPE Estimated_Mass = REAL; 
   END_TYPE; 

   TYPE Mass_Substitute = SELECT=(Weight, Estimated_Mass); 
   END_TYPE;

   TYPE Weight = REAL; 
   END_TYPE;

   TYPE Extended_Real = SELECT(FloatingNumber, NotaNumber); 
   END_TYPE;

   TYPE FloatingNUmber = REAL(7); 
   END_TYPE;

   TYPE NotaNumber = ENUMERATION OF (plus_infinity, minus_infinity, 
   indeterminate, invalid); 
   END_TYPE;

   ENTITY Steel_bar; 
      bar_length: Extended_Real; 
      bar_mass: Mass; 
   END_ENTITY;

   #1=SEEL_BAR(FLOATINGNUMBER(77.0), MEASURED_MASS(13.25));
   <STEEL_BAR id="id-1" > 
	<bar_length><FLOATINGNUMBER>77.0</FLOATINGNUMBER></bar_length> 
	<bar_mass><MEASURED_MASS>13.25</MEASURED_MASS></bar_mass> 
   </STEEL_BAR>

   #2=SEEL_BAR(NOTANUMBER(.INDETERMINATE.)), ESTIMATED_MASS(10.0));
   <STEEL_BAR id="id-2" > 
	<bar_length><NOTANUMBER>indeterminate</NOTANUMBER></bar_length> 
	<bar_mass><ESTIMATED_MASS>13.25</ESTIMATED_MASS></bar_mass> 
   </STEEL_BAR>

   #3=STEEL_BAR(FLOATINGNUMBER(77.0), COMPUTED_MASS(FLOATINGNUMBER(14.77719)));
   <STEEL_BAR id="id-3" > 
	<bar_length><FLOATINGNUMBER>77.0</FLOATINGNUMBER></bar_length> 
	<bar_mass> 
		<FLOATINGNUMBER path="COMPUTED_MASS">13.25</FLOATINGNUMBER> 
	</bar_mass> 
   </STEEL_BAR>


4. Handling of simple aggregates

   The EXPRESS attribute serves as the container for the aggregate. Every 
   element in the aggregate is represented by an XML element. For those 
   data types that are not described by entities, the name of the most specific
   type is used as the element name.

  <CARTESIAN_POINT id="cp45" > 
 	<coordinates> 
		<LENGTH_MEASURE>6.78</LENGTH_MEASURE> 
		<LENGTH_MEASURE>3.2</LENGTH_MEASURE> 
		<LENGTH_MEASURE>10.32</LENGTH_MEASURE> 
	</coordinates> 
  </CARTESIAN_POINT>

  <APPLIED_DATE_AND_TIME_ASSIGNMENT id="adta23"> 
	<items> 
		<DATED_EFFECTIVITY href="#ef-45" /> 
		<APPROVAL_STATUS> 
			<name>approved</name> 
		</APPROVAL_STATUS> 
		<PERSON_AND_ORGANIZATION href="#pno-24" /> 
	</items> 
  </APPLIED_DATE_AND_TIME_ASSIGNMENT>

5. Handling of nested aggregates

   New keyword <AGGREGATE> is used to tag each nest except the 
   outermost which is tagged by the attribute. Elements in 
   the aggregate are tagged using their most specific type 
   name.

   <RATIONAL_B_SPLINE_SURFACE id="rbss89" > 
	<weights_data> 
		<AGGREGATE> 
			<REAL>5.6</REAL> 
			<REAL>6.7</REAL> 
		</AGGREGATE> 
		<AGGREGATE> 
			<REAL>3.2</REAL> 
			<REAL>4.3</REAL> 
		</AGGREGATE> 
	</weights_data> 
  </RATIONAL_B_SPLINE_SURFACE >

6. External mapping

   Tagged using the Part 23 name generation algorithm but
   with a "-" replacing the "_and_". 

   For example, an AND/OR of foo and bar, is foo_and_bar 
   in Part 23 and is foo-bar in the AP Binding

   There is no requirement to generate the external mapping 
   names in advance.

   AP developers can use the generated names to make assertions 
   about the AND/OR instance in XML Schema at their discretion.

   Early bound implementations can choose to generate the names 
   in advance, or process the type using late bound External mapping
   software by recognizing the hyphen.
 
   #28=(LENGTH_UNIT() 
   NAMED_UNIT(*) 
   SI_UNIT(.MILLI.,.METRE.) 
   ); 

   <NAMED_UNIT-SI_UNIT id="id-28" > 
	<prefix>milli</prefix> 
	<name>metre</name> 
   </NAMED_UNIT-SI_UNIT >

7. Null ($ sign equivalent).

   The keyword NVL shall be used to indicate a NULL element.

   <position><NVL/></position> 
   <items><REAL>1.5</REAL><NVL/><REAL>2.6</REAL></items>

   When an AP developer wants to allow NULL values, the <NVL> 
   element should be included in the XMLSchema definition.

8. Attribute order.

   The attribute order does not matter. If an entity inherits two 
   attributes with the same name then qualify each name with the 
   name of the entity that defined that attribute.

   Attributes with unrecognized names shall be ignored.
   Missing attributes shall be unset.

9. Entity instance order.

   The order is unspecified. Unrecognized instances shall be 
   ignored.

10. href

   The form of an href is "document#id"

   Document shall be the URL of a file. Id shall be the id of 
   an entity instance in that file. Document may be omitted 
   if the instance is in the current file.

   The id must be a valid XML NMTOKEN (must begin with a 
   a letter)




More information about the step-manufacturing mailing list