[step-manufacturing] STEP-NC and XML as standard

[Vincent Marchetti]

I am Vince Marchetti and am responsible for the website (http://spri.kshell.com 
) that Per-Arne Carlsson mentioned in his June 10 note to the group. I  
would like to add to some of the points he made.

Per-Arne discussed the possibility of using XSLT to read the XML (Part  
28) encoding of STEP files. I recall having seen a published paper on  
this approach but I cannot recall or find by searching the actual  
reference. I'm sure it's true in a theoretical way that you can do  
anything with XSLT operating on the XML encoding that you can in any  
other programming language or discipline, but this approach becomes  
difficult because of the mismatch between the information models that  
XML/XSLT are intended for and the structure of a STEP file based on an  
EXPRESS schema. XML/XSLT works well with information that is  
fundamentally hierarchical; with things (parent-nodes) containing  
other things (children-nodes) that in turn contain other things  
(grandchildren, etc). More general relations can be implemented with  
the special xml:id attribute; but built-in support is shallow (for  
example, it's tricky to have a collection of references to other  
things). On the other hand, the information is a STEP file tends to be  
a wide-open network of things (entities); there are in fact a large  
number of entities whose only information content is links  
(references) to other entities. In short, I am skeptical about the  
practicality of using XSLT to directly work with Part 28 encodings of  
files except for very basic processing (for example, finding the  
values of the "name" attribute of product entities referenced in a  
STEP file)

Per-Arne mentioned the spri website, so perhaps I can detail it's  
relation to the points he made. That website demonstrates the  
feasibility of processing a STEP file by deriving a set of "views"  
from a single STEP file. In the terms of the STEP-NC files this group  
is interested in, one view might present a hierarchy of workplan -->  
working_steps --> toolpath; another view may present working steps  
organized by geometric and manufacturing features of the workpiece,  
another view may be organized my cutting tool requirements. Each view  
is a simplified structure, with redundant content, based on the  
original STEP-NC file. The views are designed to be readily encoded as  
XML files and readily accessible with XSLT scripts. From these XML  
views it is then possible to generate specific content such as HTML  
rendering for viewing on a browser, or for entry into a database or  
other end application, moreover with XSLT you can combine, or as they  
say on the web "mash-up", the information from several views. There is  
some progress in extracting enough geometry from the STEP file to  
deliver 3D visual representations of the products in the file as X3D  
(see www.web3d.com) files, again in XML encoding.  The generation of  
these views from the original STEP file is achieved by translating  
(through a basic crank and grind C++ application) the STEP file into   
a collection of Prolog (the computer language Prolog) assertions; then  
by analysis of those assertions with the techniques of logic  
programming afforded by Prolog (see http://www.kshell.com/prolog/pages/why_prolog/ 
  )

I see these techniques; which consume rather than produce STEP  
content; as complementary to the valuable work of this group in  
showing how to generate STEP-NC files useful for cutting actual metal.

Vince Marchetti