[wg11] RE: Specification of the AP Binding
David Price
david.price at eurostep.com
Sat Jul 17 09:21:56 EDT 2004
All,
Two points/questions:
1) The P28 default binding used the inheritance-free mapping. For
complicated EXPRESS schemas such as AIMs with lots of multiple inheritance,
I can see the rationale for doing so. For the simpler ARM schemas however, I
am not sure I see the rationale. In fact, for the STEPMod implementation we
chose to use the inheritance binding. In AP239 ARM there are only two cases
where multiple inheritance is used (in the measures bit).
One rationale for using the inheritance binding is that there are lots of
tools that can read an XSD and generate a C++ or Java API. It seemed like
with that possibility, maintaining the inheritance where possible was
useful. That way System and Requirement are subclasses of Product in those
APIs.
I worked on a data exchange project over the winter where this approach was
used very successfully. Do others see this as useful?
2) I still see problems with the architecture of the "standardize an XML
Schema in the AP document" approach discussed by Martin Hardwick. I've
raised this on the exploder in the past but will repeat for completeness. I
believe a far better architecture would be to have the AP owners create an
implementation schema in EXPRESS, rather than XML Schema. They would then
use a language they already know. Given guidelines that make the mapping to
XSD straightforward, they could get a useful XSD quite easily. This has the
additional benefit that the AIM/ARM to implementation schema mapping could
be documented in EXPRESS-X and that other implementation methods could be
generated from that same implementation schema. Wouldn't it be better to
have an XSD, SDAI C++ binding, Part 21 format and UML model all driven from
the *same* schema? The ARM/AIM could still be used for cross-AP
interoperability or classes of implementation schema documented in STEP
modules could be reused across APs in the same domain to guarantee AP
interoperability.
Cheers,
David
> -----Original Message-----
> From: Tom Rando [mailto:trando at ebmail.gdeb.com]
> Sent: 16 July 2004 23:23
> To: Martin Hardwick
> Cc: step-manufacturing at steptools.com; wg11 at steptools.com; wg3 at tc184-
> sc4.org; xmlsc4 at nist.gov
> Subject: Re: Specification of the AP Binding
>
>
>
>
> I have a couple issues with this proposal for the "simple" binding.
> It does not appear to be any simpler than the default binding
> in the current document. It contradicts many of its own purported
> requirements.
> It fails to address the major US comment regarding external mapping.
>
>
> +++++++++++++++++++++++++++++++++++++++
> >AP Binding Requirements
>
> >1. The AP binding needs to follow the mainstream conventions for XML data
> > (no surprises to the end user).
>
> - The proposed naming convention (1) is one that I have not seen used
> in any XML community. XML-ers typically prefer CamelCase for
> elements and
> lowerCamelCase for attributes. I believe this naming convention
> would come as a surprise
> to an XML-literate end user.
>
> - The examples in (3) , though only examples, contain STEPisms for
> floating point
> numbers that would also come as a surprise to XML users. They have
> adopted the
> IEEE standard for representing floating point values.
>
> - (7) introduces a STEP version of NULL. The XML community has
> already
> adopted
> xsi:nil as the out of band designator for null elements.
>
> - (8) Handling of simple aggregates will also come as a surprise
> to XML users who are used to seeing concise white-space separated
> lists for aggregates of simple values. It may also come as a surprise
> to AP209 users
> or others whose instance documents consist of voluminous aggregates
> of numerical values -- to find their instance files quadrupled in
> size.
>
> -- (10) proposes the use of fragment identifiers for local references.
> This
> runs counter to the expectations of any XML users who rely on XSLT,
> XPath or
> XML schema. Fragment identifiers do not really work in those
> environments.
>
> >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.
>
> - One of the reasons that this summary appears simple is that it omits
> the description of the accompanying XML Schema. I'm quite confident
> that
> the XML schema that is devised for this encoding will not be any
> 'simpler' than the default binding in the current draft (after the
> key/keyrefs
> are removed).
>
>
> >3. The AP binding specification must be clear, concise and precise to
> support
> > easy conformance checking by vendors and end users.
>
> -- As Gerry points out, the proposal omitted the header. Each such
> omission
> makes the proposal more complicated and diminishes the difference in
> complexity
> between this and the current default binding.
>
> -- One of most vocal complaints has been with respect to the perceived
> complexity
> of the configurability capability. (2) proposes a
> configurability option for the "Handling of entities". This should
> not
> be allowed
> in any "simple" binding. It gives the impression that we are saying
> that configurability
> is bad in all cases except the configurability option that we like.
>
> -- (3) describes the notion of a path for SELECTs. I do not believe
> that
> traditional XML developers, such as those that Dave Price deals with,
> will
> find this concept clear and precise.
>
>
> >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.
>
>
> Why? What is the world-wide population of those who have developed
> P21 parsers? Is it over five? The paramount reason for using XML
> is to take advantage of the universally-available XML parsing tools.
>
> >5. The AP binding must allow AP implementations to inter-operate when
> > those AP's contain harmonized AIM definitions.
>
> Nothing in the proposal addresses interoperability across schemas.
> This
> is accomplished in the XML world by means of XML namespaces. The CD
> P28
> document addresses namespaces. The inclusion
> of namespaces in the "simple" binding introduces yet another layer of
> complexity.
>
>
>
>
>
>
> OTHER RAMIFICATIONS
>
> 1 ) The proposal for external mapping (6) violates the major US
> comment
> to support a late binding approach. This proposal is no different
> than the approach in the current Part 28. The problem in both cases is
> the
> impracticality of generating XML schema for EXPRESS schemas that
> implicitly
> define a huge number of complex entity types. It adds nothing to say,
> "There is no
> requirement to generate the external mapping names in advance." If
> explicit
> names are used they must be generated in advance in order to create an
> XML schema.
> The only alternatives are to generate the XML Schema at runtime after
> the
> instance population is known OR to loosen the XML Schema so that any
> entity elements
> are allowed. Of course, the latter means that the XML schema no longer
> validates even the
> structural constraints on the data and, in fact, validates nothing at
> all.
>
>
> 2) The proposal for order independent attributes (8) means that the
> resulting
> XML schema must be an inheritance-free schema. The Part 28 team has
> spent a lot of time
> dealing with the fact that if XML schema inheritance is used, then it
> is not
> possible to support order-independent attributes. The upshot of this
> is
> that
> the simple mapping fails to satisfy the requirements of those who want
> an inheritance mapping. Most notably, the simple XML schema will not
> be
> useful
> to those that plan to use Microsoft tools to generate data objects (eg
> AP210 team,
> PLCS users, et al.).
>
>
> 3) I keep hearing that the simple binding should be like Part 21 but
> once a specific
> proposal is made, it is clear that this statement is misleading. Part
> 21 relies on
> the order of attribute values (and their explicit association to an
> accompanying EXPRESS
> schema) in order to marry values with their attributes. XML is
> fundamentally different;
> it uses tags in the instance data and does not require ordering.
>
> As Gerry points out
> the identifiers in P21 are integers; XML identifiers must start with a
> letter.
>
>
> Unlike Part 21, well-formed XML requires a root element.
> The current proposal does not address how the root element is
> designated (that would make
> the proposal more complicated).
>
>
>
>
> ==========================================================================
> ==================
>
> The following is a proposed:
>
> +++++++++++++++++++++++++++++++++++++++
> 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 wg11
mailing list