[step-manufacturing] RE: [wg11] Part 29 Specification of the AP Binding
Hunten, Keith A
keith.a.hunten at lmco.com
Wed Jul 28 14:53:46 EDT 2004
-----Original Message-----
From: pfAeroFW, ISOWG12
Sent: Wednesday, July 28, 2004 8:10 AM
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 step-manufacturing
mailing list