Is Mstn CE now 100% C++ ?

Just wondering if all that JMDL stuff is now incorporated as part of MstnAPI.

Class com.bentley.dgn.ArcElement now rebooted as Bentley.Geometry.Common CircularArc?

All that JMDL Schema and Component stuff now part of ecsdk?

Parents
  • Hi dominic,

    what does it mean "to be 100% C++"?

    As I am not Bentley developer, I don't know what parts of MicroStation are written in what language, but for the whole history MicroStation is primarily developed using C and now C++. From (at least) MicroStation V8 XM Edition some functionality is developed using NET Framework, in CONNECT Edition e.g. the whole GUI (based on Telerik GUI libraries). Maybe some parts are developed using other languages better suited for an implementation of a particular functionality.

    JMDL is dead from MicroStation 8.0, so it sounds strange to ask about JMDL API in CONNECT Editionas there is 15 years gap between them.

    There are different APIs available in CONNECT Edition and every API offers own approach to MicroStation and design file content. MDL C approach using Element Descriptors is still used but treated as obsolete and replaced (step by step, not completely yet) by C++ API based on Element Handlers. There is still VBA/COM object model and also new NET API (DgnPlatformNet), more similar to C++ API than to former VBA/COM API.

    With regards,

    Jan
  • Jan,

    I am not asking about what API's are available. Just whether CE is 100% C++ or not.

    Rewinding even further back to ProActiveM (p377) I wonder if Objective MicroStation has finally arrived :-)

    The whole Schema thing seems to be pretty Bentley ECM-centric. Looking back at what little has been published, it seems to be very much about OO / component-based programming principles that are somewhat aligned with BIM 'building object behaviours' thinking with a bit of Semantic Web ideas in the background.

    Do third party developers always provide schemas which seems to be a means of exposing their 'interfaces' or is it only the Bentley guys who do it? Seems like additional work... or is it really just a normal Bentley C++ API flavour of OO-programming practice of creating classes and interfaces etc.

    What are the benefits? One of the benefits of using Schemas mentioned all those years ago was that the Schema can be extracted in different file formats tailored to different tasks/apps. An 'energy schema' was mentioned that would allow an environmental engineer to run analysis on the same model as the architect. ISM for environmental engineering? I suppose that this would fit in well with Greg Bentley's ideas about the need for more Analytical Modeling apps.

  • Hi dominic,

    I have to admit I don't understand and don't know how to handle this discussion. Individual topics are interesting and important, but all together, also because it's not always clear in what meaning you use some terms, is a mishmash. Right now my feeling is you try to discuss particular software development aspects (like C++, API structure) together with high level general concepts (idea of object modeling) plus independent concepts that don't relate to the development itself (schemas, if you mean EC schemas).

    Unknown said:
    I am not asking about what API's are available. Just whether CE is 100% C++ or not.

    Sorry, still don't understand the question at all. Can you explain what do you mean by "is 100% C++"? Do you want to know if MicroStation is written using C++ only? In such case I already answered the question: MicroStation is written using different languages, at least by C++ and NET (I guess mostly C#, but it doesn't matter). Or you are asking if and what object oriented design rules (like SOLID) are applied? In such case I don't know and I don't care about it completely. For development the only important criteria is how internal functionality is published (through APIs). And the same feature can be published in many different ways (C style in MDL API, more object oriented C++ API or VBA API).

    DGN V8 is format based on Microsoft's Compound File specification, where data are stored in streams as binary structures. There is no any "object oriented feature" available in the format specificaiton and any "intelligence / rules / dependencies" has to be implemented on top of this format using code, as was done e.g. with EC schemas (which itself are stored using XAttributes that are one from several available concepts how to store non graphic data inside DGN file).

    Unknown said:
    Do third party developers always provide schemas which seems to be a means of exposing their 'interfaces' or is it only the Bentley guys who do it?

    Again, don't understand what are you asking about. What do you mean by "schema"? Usually if "schema" word is used in MicroStation context, it's EC Schema, which is formalized way how to defined and store metadata (data about data), so any application, if EC Schema is available, is able to interpret the data (but not necessarily to create them or edit them). EC Framework concepts is used widely in Bentley products in many different ways: From quite simple to attach custom data to an element in a standardized way. so MicroStation is able to display it without original application (e.g. when SHP file is attached or imported, or Item Types in CONNECT Edition) to very complex like .imodel where the whole i-model file is described using different schemas and stored in SQLite database. EC Framework is not related anyhow to API or how MicroStation core is written, this is primarily concept at the same level as .xsd files (metadata written in XML defining data in another XML file).

    Unknown said:
    One of the benefits of using Schemas mentioned all those years ago was that the Schema can be extracted in different file formats tailored to different tasks/apps.

    Yes, it's available, it works perfectly, just it will take time when application will be able to utilize this concept. But it has nothing to do how MicroStation is written (if using C++, C, VBA or whatever else) and also not related to CONNECT Edition. EC Schemas are used for years and years, there are now more visible to end users as more tools and products are able to use this approach.

    So there can be element with different data attached, one based on "building schema" and another based on "environment protection schema" and any MicroStation application is able to access the data without the original application has to be presented. Without EC Schema, the data will be just binary mess. With EC Schema, MicroStation and other applications know this is e.g. string and should be displayed using this formating and this caption. These data can be extracted (e.g. using i-model ODBC driver or some SDK / API) or if published in i-model, converted, transformed etc. (using i-model transformer).

    Unknown said:
    But if you read the JMDL link Schema seems to describe a class hierarchy.

    Again, I see some unclearness what do you mean by "schema". I am not aware about any typical meaning in relation to API documentation (API structure or object model terms, for object oriented languages, are used usually). But API often has no direct relation how code is implemented internally, because of different purposes: application core can be implemented with performance, portability or maintenance priorities, while API are designed to provide systematic approach to application features. And because every language is different, for the same product different APIs will have different structure. I can imagine C++ API will not provide some features because of lack of runtime reflection comapring to C# and e.g. F# API (doesn't exist in MicroStation) would be "functionally oriented".

    Unknown said:
    JMDL apparently was a pretty productive API

    Probably not enough. Because if it was really productive, it should be not removed from MicroStation. It's true JMDL as the first defined some API concepts that are now used in DgnPlatform library (C++) API and DgnPlatformNet (.NET) and .NET, but concept of Element Handlers, which is preferred approach now, was not available in JMDL.

    Unknown said:
    KB spoke about an inflection point when the amount of non graphic data would overtake the graphic/geometric data in your typical dgn.

    Yes, it's happening step by step. MicroStation for last several years has provided ability to work with "application internal" non graphic data (e.g. in AECOsim data defining different aspects of building model, that don't understand any other application) and "public" non graphic data (data that can be presented outside). The "public data" are available through their own EC Schemas dynamically (in memory representation ensured by original application) or converted and attached to elements like EC objects (no original application is required to read the data).

    With regards,

      Jan

  • Jan,

    You obviously haven't bothered to read the links in the previous posts. Maybe someone at Bentley should give us the 'history of Schema. Don't shoot the messenger.

    What am I trying to get at? Who knows? Do you always start a question knowing what the answer will look like? Not even school teachers are allowed to do this these days. Something the UK is trying to fix apparently:-).

    Having said that, I am interested in Bentley's approach to what is these days called BIM. If you think that there is lack of clarity about Schemas you should take a look at BIM. Anyway, BIM is big and here to stay for the medium term at least. One of the core ideas was capturing and encapsulating behaviours of real world objects like doors, valves, beams etc as digital simulacra complete with its behaviours. In B F Peter's paper on Mstn Modeler, linked previously, this went beyond CSG features and was to be addressed by addind Schemas. I think that he was alluding to the thinking behind Semantic Web, KBE programming where complex behaviour can be made 'machine readable' using rules.

    I don't think this way of doing things ever got very far. Buildingsmart and IFC or Fiatech and ISO 15926 are still struggling. What has sort of happened is a lot of work on trying to standardise the way information is formated for those same objects, so that information can be reported on without the original authoring app. From your previous post, this seems to be in line with how the third party dev uses EC Framework (EC=Engineering Component?)

    But this is only the tip of the BIM iceberg. Interoperability is not the same as integration. At some point, the user will need to manipulate the information outside its authoring app. Let's take the architect verus environment engineer scenario. Architect models house. House has external walls and windows with different heat loss characteristics. He needs to use a energy analysis tool to check and to use an external tool and analyse the model... and append his data to the model. Old hat. But, we quickly realise that in a production environment we also need to CHANGE the model in the external app and return orr roundtrip the modle back with thicker walls or smaller windows or even different orientation etc back to the architect for reviews and more fiddling.

    Structures has had some success with this using ISM's. Grids originating in a design app can be modified in an analysis app before being checked back in to the repository with transaction control. ProjectBank incarnate?

    Open plant even has something called Consensus Schemas that allow some out of app modifications. It is also building in Prostructures into OP. Before you write back saying I am not clear about what I mean by Schemas here... :-)

    The JMDL link to the old help file has tabs to Schema and Schema Tree. You'll have ask Bentley why they did that. However, what is interesting is that there seems to be a list of methods that give the user/programmer access to the underlying data. Open plant has a similar function that allows user to access a pipe object (Component in Bentley speak?) via its Schema in the Class Editor. The pipe's z vàlue is extracted by calling a method on the pipe object and used to calculate another property using an expression and marked for display in the Properties panel. I suspect that you won't be able to do this with a their party app that did not publish its Schema.

  • Some interesting writings on 'Schemas' and OO computerized modeling systems (CMS) from the patent office...

    patents.justia.com/.../6063128

    Goes beyond provding a spec so that the attached attribute information can be edited... but alos access to the associated object.
Reply Children
No Data