[step-manufacturing] Re: Question to AP owners/implementors on XML Schema use (Part 28 Edition 2)

Martin Hardwick hardwick at steptools.com
Mon Jun 7 13:11:22 EDT 2004


Ed,

Here are the AP-238 requirements for P28:

1. Want to represent ARM objects in the data in a way that
   allows users to mix AIM and ARM representations so
   that the direct ARM representation can be used when it is
   sufficient and the more complex AIM representation can be
   used when it is necessary.

2. Want it to be possible for a property of an ARM object (aka 
   ARM attribute) to be represented as:

   a) a Mapping path
      e.g.For a Round_hole object diameter:
        <DIAMETER>
                <Round_hole-Instanced_feature ref="id-4096" /> 
                <Product_definition_shape ref="id-4097" /> 
                <Shape_aspect ref="id-4098" /> 
                <Shape_defining_relationship ref="id-4099" /> 
                <Circular_closed_profile href="ROUND_HOLE.xml#id-8096" /> 
        </DIAMETER>

   b) a direct ARM representation (with an XML Schema definition)
      e.g For a Round_hole object diameter
        <DIAMETER>0.39</DIAMETER>

3. Want to represent a mapping path as a sequence of identified
   elements in the AIM (paper available to describe why)

4. Want it to be possible for the AIM elements in the path to be stored:
   a) in the same file as the ARM object (modularity)
   b) in the file being used to represent another ARM object
   c) in a P28 file
   d) in a P21 file (mostly for geometry)
         
These requirements are in top down order with each more or less
describing a solution for the previous higher level requirement.

We can meet these requirements by extending P28, or by writing an
Annex to AP-238 that references P28 for the definition of the 
AIM elements (when they are described using XML). If the
P28 definition of the AIM elements is too obtuse/sophisticated then
we will be tempted to put a more direct definition into an informational
section of the AP.

Martin



At 02:29 PM 6/4/2004 -0400, you wrote:

>Martin Hardwick wrote:
>
>>Does the package/wrapper belongs in Part 28? It is a technique that
>>is useful for STEP AP's that have an AIM and an ARM but I am not
>>sure about other applications.
>
>As long as the standard allows you to use the feature and doesn't try to make rules as to when you have to, I think it is just a "feature".  The "package", however, could only occur as an immediate child of the uos, which may not satisfy your needs.  As a child of the uos, it is just a user-defined subdivision of the data set -- its immediate children (entities) are interpreted as being immediate children of the uos.
>I don't see that it is inappropriate to permit user-defined subdivisions of the data set.  After all, APs define "units of functionality" in EXPRESS schemas with no corresponding EXPRESS construct, and Part 21 used to have the &scope construct, even though there was (regrettably) no corresponding EXPRESS construct.  And both of those ideas might be reasonable uses of a "package" feature.
>
>Trying to put a package anywhere else, i.e. as a component of an aggregate value or as the value of an attribute, creates problems. Which entity in the package is the attribute/component value?  And what are the others doing there?  If all the elements in the package are parts of one logical (ARM) object, isn't there some *inverse* configuration directive and by-value arrangement that would allow them all to be incorporated into the XML composition of the one that has the data type specified in EXPRESS?
>
>I'm not really arguing for the idea.  I'm just saying the basic "package" feature is neither bizarre nor difficult to add.  OTOH, I doubt that it is what you really want.
>
>-Ed
>
>-- 
>Edward J. Barkmeyer                        Email: edbark at 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."




More information about the step-manufacturing mailing list