Dear Steve, The OMG CAD Services (OCS) specs are still freely available from the OMG website (the latest release is 1.2 : http://www.omg.org/spec/CAD/). I agree with you about the fact that the OCS is a good starting point. I briefly studied the OCS some months ago, and have a few notes I'd like to discuss with you:
- from a technical viewpoint, the CORBA technology is perfectly suitable for synchronous sharing of business objects through a network. In my opinion, an asynchronous collaboration should be enough (regarding the business needs related to usual CAD workflows) and Web Services (WSDL, SOAP etc.) might just be perfect; - from a semantic viewpoint, whereas the computational model is explicit, the informational model is mostly implicit. For instance, the CadBrep::Face class definition could be whatever. In my opinion, it could be a good thing to harmonize the semantics contained in the OCS and the STEP parts 42, 55 etc.; - some of the methods defined in OCS are strongly platform dependent: for instance CAD User Interface, paths etc. A high level CAD API should abstract these concepts and be platform/CAD system independent; - at last, I have a few doubts about the persistent identification since I know it's still considered as a major issue. And I wonder whether or not the OCC topological naming could be mapped to these persistent_ids. Best Regards, Thomas 2010/12/12 Stephen Waterbury <water...@pangalactic.us> > Thomas, Dan, Dave, > > A precedent (or at least a closely related concept) was the "CAD > Services API" developed by the [now defunct] OMG Manufacturing > Technology & Industrial Systems Task Force (MANTIS). That > specification is no longer active. It basically fell prey to > the OMG rule that an active spec must be implemented by at least > 2 vendors -- it was only implemented by one vendor (see below) -- > but it represents some good work that is still potentially > useful. > > The fact that only ITI had a product that implemented the CAD > Services API specification is more an indication of the hesitancy > of CAD vendors to provide a standardized API than of the quality > of the spec, IMO. ;) I've put a copy of its last version on my > web server for convenience (not publicized since I think OMG's > copyright might still be in force, not sure -- but since NASA > contributed to the spec, I feel somewhat justified in making it > available!): > > http://pangalactic.us/cax/CAD_Service_V1.1_030363.pdf > > It's interesting to note that both NASA *and* OpenCascade > contributed to the spec. It is based on the API of "CADScript", > a set of Python wrappers for CAD tools that was developed as a > commercial product by Doug Cheney of International Technegroup > Incorporated (ITI). CADScript is no longer offered by ITI as a > product, but Doug (who is a strong python advocate) has used a > Python API internally for another ITI product of which he is the > primary developer, called CADIQ, which analyses CAD models for > various types of modeling errors that could lead to data exchange > problems or manufacturing problems, for example. (The CADIQ url > is: http://www.transcendata.com/products/cadiq/) Doug presented > the CADScript product at the PDE 2001 Workshop at JPL. His > presentationslides are here: > > > http://step.nasa.gov/pde2001/STEP-and-Scriptable-CAx-Tool-Integration_Doug-Cheney.ppt > > Doug also did an impressive live demo using CADScript for the > Multi-CAD Assembly use case shown in his next-to-last slide. > Also, from recent conversations with Doug, I know that users of > the current CADIQ product can be given access to the supported > Python API that it uses (not sure how much of CADScript might be > there). > > I agree with what Thomas proposes below -- the concept of a > standardized high-level API that would have a standardized > framework or methods to specialize it for particular use cases. > I'd suggest considering the CAD Services API specification as a > starting point for a high-level API, since that spec incorporates > a substantial amount of harmonization work that was done to > develop a consensus high-level CAD API, and I think if pythonOCC > provided a high-level API that implements even something close to > the CAD Services API, it could provide a de facto industry > standard high-level CAD API, with the hope of getting it adopted > by other tools, and in the future possibly made a formal standard > (by OMG, ISO/IEC, or whomever). > > Cheers, > Steve > > > On 12/11/2010 03:47 PM, Thomas Paviot wrote: > >> Dear Dan, Dave, >> >> I didn't know about the openscad project, thanks for introducing me this >> project. Dave, you write "it is a tool that allows programmatically >> building >> solids using python and a CSG kernel", but I don't see any python >> scripting, I >> have rather the feeling that the scripting language of openscad is a kind >> of >> specific language, am I wrong? >> >> I agree with both of you regarding the high-level API that could be built >> upon >> pythonOCC. Abstracting the low-level OCC api/data model would be something >> really helpful. From a development viewpoint, there is not big issue : we >> all >> developed or our own classes/methods or function in pythonOCC in ordre to >> speed up development and make our programs modular. The big deal is rather >> : >> what classes/methods should be made available to the user? How could this >> set >> of functions be complete, i.e. how to ensure that *all* the needs from any >> user are covered by this API ? >> >> In my opinion, there's no way to get it done (I've been thinking about >> this >> for a long time). We'll always find a user that is not satisfied with the >> API >> and who requests for another method/class etc. The risk is then that this >> high >> level API become as big and complex as the original one (OCC). >> >> We could then imagine a different workflow than the usual one. I think >> about >> something that was used for the standardization of the AP239 of the STEP >> standard (also known as PCLS) : a very generic data model were designed >> (and >> standardized), and the specialization of the data model was also >> standardized. >> As a consequence, users with very specific business just join their >> efforts to >> define a standardized specialization of the generic data model suitable >> for >> their needs (aviation maintenance, operational feedback etc.). >> >> This development model could be moved to the pythonOCC high level API >> development : >> >> * a generic data model would be defined, with basic and fundamental >> elements ; >> * a framework for specializing this model is also defined. Both of this >> two points could be viewed at an ontological level ; >> * we then set up a 'high level API' repository with a set of basic >> classes/methods already defined ; >> * from these 2 points, we just let the user contribute new >> classes/functions/methods if what he is looking for is not already >> available from the repository. >> >> It could be a way for us (developpers of pythonocc) to share the >> development >> efforts of this needed high level API. And to have, as a consequence, a >> huge >> web-based repository of python classes/methods/functions, classified by >> businesses (FEM, manufacturing etc.), level of granularity, functions >> (gears, >> bearings etc.) etc. >> >> pythonOCC would then become a kind of distributed library : a core >> component >> (the python wrapper), required, and thousands of optional components >> available >> online, supported by a powerfull request engine. Setting up such an >> architecture is more a scientific project than a simple python development >> activity. >> >> What do you think about that idea? >> >> Thomas >> >> 2010/12/11 Dave Cowden <dave.cow...@gmail.com <mailto: >> dave.cow...@gmail.com>> >> >> >> Yes, definitely a higher level of abstraction is needed than just pure >> python. >> >> I am thinking ( not surprisingly ) of an environment a lot like a java >> ide. You write code, but the ide provides syntax highlighting, >> function completion, refactor support, code templates, a way to >> include other libraries, etc. >> >> On 12/10/10, Dan Falck <dfa...@frontier.com <mailto: >> dfa...@frontier.com>> wrote: >> > Yes, this technique does work- I've used it for commercial design >> work >> > with some proprietary modelers (Ashlar Cobalt and PunchCad Shark FX) >> > that used a crude scripting language-called of all things 'Macro >> > Parser'. I was able to make simple changes to the scripting that >> would >> > be major changes to the model. This allowed for very flexible >> revisions. >> > It also made it easy to recover from a crash if the application was >> > acting finicky. >> > I was able to do fork crowns for bicycles (classic Italian style-not >> the >> > modern stuff) by using techniques that emulated a cnc mill tool path >> > through the solid block. The whole time I was working the model as a >> > machinist would at a mill or lathe- subtracting shapes from the >> solid >> > that I started with. Python code was necessary to keep me from >> losing my >> > mind during these projects :) I created some functions that made >> dealing >> > with the crude 'Macro Parser' scripting a lot easier. >> > PythonOCC looks a whole lot more attractive to me than my old work >> with >> > this crude scripting. But, I would like to be able to abstract it a >> > little more though to make it easier to remember how to use it, >> without >> > having to go to the OCC docs all the time. I would bet that Thomas >> and >> > Jelle are working on something like this. >> > I think this project might be similar to what we are talking about: >> > >> > http://www.caddd.org/ >> > >> > Dan >> > >> > On 12/10/10 2:27 PM, Dave Cowden wrote: >> >> I assume that someone has seen this: >> >> >> >> http://openscad.org/ >> >> >> >> it is a tool that allows programmatically building solids using >> python >> >> and a CSG kernel. >> >> >> >> If such a tool used pythonOCC instead, it would be _much_ more >> powerful. >> >> >> >> This kind of tool is really interesting to me. Anyone who has done >> >> much solid modelling for a living quickly realizes that a complex >> >> solid model is much like a programming problem. You cannot just >> >> 'start building' a complex model: you have to plan how the object >> is >> >> built, which references are used, etc, so that the object is >> >> extensible and easily changed to accommodate design iterations. It >> >> becomes really important to plan reference planes and other >> reference >> >> geometries to reference each other in a way consistent with the >> rest >> >> of the model. >> >> >> >> Using a programming language to capture the [currently always >> >> proprietary] way that solid modelling packages capture the build >> order >> >> and dependency chains of a solid ( especially parametric solids ) >> is >> >> brilliant. As programmers, we are very familiar with the ability >> to >> >> use CVS merge and other utilities to track fine-grained changes to >> >> software over time, even when under concurrent development. Imagine >> >> the power of this capability applied to scripts that produce solid >> >> objects! No more huge binary solid object files that are opaque >> from >> >> a change management viewpoint! >> >> >> >> Does anyone know if such a package is underway anywhere based on >> >> pythonOCC? >> >> >> >> >> >> >> >> _______________________________________________ >> >> Pythonocc-users mailing list >> >> Pythonocc-users@gna.org <mailto:Pythonocc-users@gna.org> >> >> >> https://mail.gna.org/listinfo/pythonocc-users >> > >> >> -- >> Sent from my mobile device >> >> _______________________________________________ >> Pythonocc-users mailing list >> Pythonocc-users@gna.org <mailto:Pythonocc-users@gna.org> >> >> https://mail.gna.org/listinfo/pythonocc-users >> >> >> >> >> _______________________________________________ >> Pythonocc-users mailing list >> Pythonocc-users@gna.org >> https://mail.gna.org/listinfo/pythonocc-users >> > > > _______________________________________________ > Pythonocc-users mailing list > Pythonocc-users@gna.org > https://mail.gna.org/listinfo/pythonocc-users >
_______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users
