FW: [wg11] Part 29 Specification of the AP Binding
David Price
david.price at eurostep.com
Wed Jul 28 09:49:14 EDT 2004
Keith asked me to send this along.
> -----Original Message-----
> From: pfAeroFW, ISOWG12 [mailto:ISOWG12 at IMC7.EMS.LMCO.COM]
> Sent: 28 July 2004 14:10
> To: David Price
> Subject: RE: [wg11] Part 29 Specification of the AP Binding
> Importance: High
>
> All -
>
> I agree completely with David - I think it would be far preferable to
> work this through the system, otherwise we will be defeating ourselves
> by putting out two solutions. A simple "AP binding configuration"
> definitely needs to be in Part 28, and the process of ballot comment
> resolution will ensure this as there have been many comments submitted
> on this subject.
>
> There has been a lot of good work here - let's apply it and the
> accompanying energy to the Part 28 effort and get it out that much
> sooner!
>
> Keith
>
> PS - Dave - I only see this as addressed to 'WG12' - would you please
> circulate it to others/exploders as needed.
>
> -----Original Message-----
> From: David Price [mailto:david.price at eurostep.com]
> Posted At: Tuesday, July 27, 2004 6:34 PM
> Posted To: ISOWG12
> Conversation: [wg11] Part 29 Specification of the AP Binding
> Subject: RE: [wg11] Part 29 Specification of the AP Binding
>
>
> All,
>
> From an ISO standard/procedural point of view, I cannot see how a
> separate Part 29, requiring development and the required CD/TS or CD/DIS
> ballot, can do anything but delay getting XML Schema capability into the
> hand of AP developers.
>
> As Part 28 has passed its CD ballot and will be a DIS within a few
> months, I would encourage efforts to satisfy these requirements within
> the current Part 28 Edition 2 framework rather than in another SC4
> standard. Even if an "AP binding configuration" was required to be
> standardized as a clause in Part 28 in order to achieve this, that seems
> a better option than creating a separate standard.
>
> Cheers,
> David
>
> > -----Original Message-----
> > From: wg11-bounces at steptools.com [mailto:wg11-bounces at steptools.com]
> > On Behalf Of Martin Hardwick
> > Sent: 27 July 2004 21:31
> > To: xmlsc4 at nist.gov; wg11 at steptools.com;
> > step-manufacturing at steptools.com; wg3 at tc184-sc4.org
> > Subject: [wg11] Part 29 Specification of the AP Binding
> >
> >
> > All,
> >
> > Here is a draft formal specification of the AP binding.
> > The document is as per the message I sent out just before
> > the last conference call but with header elements defined
> > and two corrections made:
> >
> > a. NVL element deleted and replaced with an unset attribute. b. Camel
> > case used for entity names.
> >
> > I had the following goals when defining the header element
> >
> > 1. Make it possible to embed STEP information in other XML
> > documents including SOAP envelopes and databases. For example,
> > send the header element to a user in a SOAP message and have
> > it contain URL's for all of the places to find the data.
> >
> > 2. Enable the reuse of data across Application Protocols including
> > reuse of geometry defined in P21.
> >
> > 3. Enable the definition of constant entity instances in a reference
> > data set so that they can be reused by every instance of an
> > Application Protocol (and be defined by standard names given in the
> > AP).
> >
> > 4. Enable modularity by defining a new class of conformance checking
> > that allows the mapping of an Application Object instance to be
> > checked without checking the rest of an AP.
> >
> > This should make it possible for us to begin defining re-usable
> > libraries of Application Objects which is something we need quite
> > badly in STEP-Manufacturing so that we can start defining libraries
> > of re-usable processes and features.
> >
> > 5. Give the user freedom to define name spaces for STEP data and name
> > spaces
> > for other kinds of data and allow the two to be freely mixed within
> > documents.
> >
> > I welcome all of your comments and will be happy to make corrections
> > and add functionality.
> >
> > I have not done anything to optimize the representation of lists
> > because I would like to talk to the group working on the
> > representation of large analysis data sets to discover what will work
> > best for them (simply allowing lists of primitives to be compressed
> > seems insufficient).
> >
> > This work is not meant to replace P28 but to supplement it for those
> > teams that do not anticipate being able to define a simple XML Schema
> > for their Application Protocol in the short to mid-term.
> >
> > In this edition the text and table of contents are good (for a draft
> > rapidly written by one person). The index has not been updated. None
> > of the Annexes have been updated, but some P21 annexes that do not
> > apply to P29 have been deleted. I have not yet figured out how to use
> > the Framemaker spell checker without it complaining about all the
> > examples so I apologize in advance for all the typos.
> >
> > Martin Hardwick
> >
> >
> > At 01:51 PM 7/16/2004 -0400, Martin Hardwick wrote:
> >
> > >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)
> > >
> > >_______________________________________________
> > >wg11 mailing list
> > >wg11 at steptools.com http://lists.steptools.com/mailman/listinfo/wg11
> > >
> > >
> > >!DSPAM:40f815d4183261392010872!
More information about the wg11
mailing list