Items & Item Types - What's in it for Mstn?

Lots of confusion about Items v Item Types in the forums. My understanding is that its all based on the shadowy advance of Bentley's EC Frameworks APIs, which I first heard about as Bentley's secret weapon used to consolidate MX, Geopak and Inroads into OpenRoads. Then started making an appearance in OpenPlant and its Class Editor, as a means to manage ISO 15926 schema (object-oriented in relational database friendly format?) info. EC Attributes also described as Bentley's version of AutoCAD's XAttributes. Guess that this needed for direct reading / writing all those dwgs.

Now in Mstn CE, Items seems to be the go-to enabler for data-centric (Hey, Mstn is BIM not just CAD, y'know) workflows like Property based Annotation, reports, parametric variables, business info, property panel display, queries etc. Items since V8i has been able to access Mstn's elements or 'schema' and I suppose some of Bentleys verticals (OpenRoad, Plant) and is providing some plumbing to verticals like OBD to use the same tools like the Properties Panel and Parametric Cell Variables.

All great great stuff. OTOH, this is taking so long and the results drip-fed over so many years, I can't help wondering whether we know what we really really want from Items and small brother Item Types, as users. I am sure that they are great for all kinds of programming reasons 'under the hood'. In fact, I wonder if Bentley high command have a clear idea, given the slow -seemingly tentative- pace of development.

Some of the benefits are already clear. Mstn has always been very good at CAD, but not so great with data-centric BIM working, which would normally need addons. Providing all of that at platform level is welcome. Ditto for the parametrics, smart annotation and business info attachment stuff. Common data and modeling platforms would pave the way for 'open' cross vertical working. Something that doesn't work very well even within the Bentley family of apps. Try printing from a file that has OpenRoads and OBD etc content for example.

Some of the dis-benefits are also becoming clear: extracting, converting all that non-graphic info for display and data-centric 'BIM' manipulation will make your file loading, model switching etc slower. More resource to convert existing app code will mean slower bug fixes, fewer new features etc.

Parents
  • Hi Dominc,

    as often in your case, pretty long text, where I am not sure what is its intention: Is it question, complain, blog, a summary of personal ideas? Plus, not always correct, sometimes based on facts, sometimes on incorrect subjective assumptions, merging together different "levels" (persistence technology vs abstraction concepts...).

    So it cannot be answered in an organized structured way, only fragments commented...

    Lots of confusion about Items v Item Types in the forums.

    I do not think "lots of confusion". Please, provide evidence.

    I agree it can be confusing, especially when not enough knowledge is available, but I remember one recent discussion only.

    My understanding is that its all based on the shadowy advance of Bentley's EC Frameworks APIs

    Yes, it is more or less correct. Jon is wrong, because underlying technology is not EC Schema, which is only one part (aspect) of the technology, used for one specific task. Your naming "EC Framework" is better, because it can be split into things like formalized data structure definition (EC Schema), formalized data storage (EC instance), both covered by ECXML specification, and APIs in C++ and NET. Plus, there are topics like persistence, because it can be on-the-fly in memory, in DGN format, serialized to database (like .imodel based on SQLite).

    into OpenRoads. Then started making an appearance in OpenPlant and its Class Editor

    I am pretty sure it was opposite. Idea of engineering objects abstraction and formalization came from plant world (e.g. ECXML format was standardized before 2005!), used years ago in ProjectWise services, and step by step introduced to desktop products. It was  (and still it is) slow process, because it requires to change mindset completely.

    EC Attributes also described as Bentley's version of AutoCAD's XAttributes.

    I do not know AutoCAD XAttributes, but I think it is incorrect and bad statement, maybe a result of misunderstanding what EC objects are. EC world is from very beginning designed to be platform agnostic / neutral, and only fractions (like how data is saved in DGN format) depends on MicroStation and DGN.

    Item Types

    Item Types are nothing else than user-level tool, based on EC Schema. Whereas developers are able (I do it quite often) define own EC Schemas, describing custom data structures, including relationships between objects, Item Types are based on one pre-defined EC Schema "template", that is used to create EC Schema at background for every Item Type library, that is created by user.

    It specifies existing limits: Item Types cannot include anything, not allowed be EC Schema (and because the technology itself is rigid and strict to universal and do not depend on specific platform or program, there are plenty of limitations and rules defined ;-) Also, when application support is required (e.g. Symbol Provider has to be written to offer functions for EC Expressions), it must be done very carefully to maintain backward compatibility (both with MicroStation, as well as other existing tools).

    and I suppose some of Bentleys verticals (OpenRoad, Plant) and is providing some plumbing to verticals like OBD to use the same tools like the Properties Panel

    It is more complicated:

    Internally:

    • Some applications are "EC Schemas" based, like civil products (OpenSite, OpenRoads, OpenRail) and plant (OpenPlant). They use EC data directly, both to save them in DGN, as well as to create data models in memory on the fly (when necessary).
    • Other (like OpenBuilding Desginer) do not use EC data natively. It is just because of the product history, when it was not re-implemented, but only migrated (on civil products can be seen, how complicated such process can be).

    GUI level:

    • When data is natively stored in EC format, they can be displayed automatically by MicroStation. It is good especially when data is "flat" and no dependencies or restrictions exist (like when SHP data is imported).
    • Sometimes EC data is displayed not 1:1, but further modified, both using EC Schema customization and application code.
    • When data is not in EC, EC adapters can be implemented , so proprietary formats are converted to EC representation. It is used by MicroStation also, when DGN format and element data (not based on EC) is available to the rest of MicroStation through unified "EC language".
    I can't help wondering whether we know what we really really want from Items and small brother Item Types, as users.

    You can want only what is defined in EC specifications, created nearly 20 years ago ;-)

    I think you hit one topic, that is often a source of confusion and misunderstanding: EC<whatever> is technology how to describe data structure and how to save data in this structure. Nothing else, nothing more, no exception. Everything is else is not "EC", but just application layers and tools, build around EC world.

    So, what EC technology can do more for you? Nothing else than store data.

    But, how we can use this unified way, how data is described and stored, in new ways? There are no borders, it depends on fantasy (and development skills) only ;-)

    I wonder if Bentley high command have a clear idea, given the slow -seemingly tentative- pace of development.

    I think that EC (and the whole MicroStation) is stabilized, but a bit obsolete, technology, from Bentley perspective.

    The most investments, and the fastest development, is in iTwin.js and iModelHub projects, based on EC successor (BIS schemas were created using 20 years of experience with EC in server and desktop implementations).

    Something that doesn't work very well even within the Bentley family of apps.

    It is not simple task in general, because even when EC allows to read data in standardized way, often it is not clear how they can be interpreted without knowing wider context or to have authoring application. Especially, when plenty of data - typically defining relationships, further conditions and abstract models - are not specific to particular element, but stored in model.

    Regards,

      Jan

  • as often in your case, pretty long text, where I am not sure what is its intention: Is it question, complain, blog, a summary of personal ideas?

    HI Jan, its always good to hear from you... honestly!

    Length: Yes, I know. You should be getting used to it by now; The biggest clue is in the title : Whats in it for Mstn?

    I do not think "lots of confusion". Please, provide evidence.

    You correcting Jon goes a long way to answering your own question. See also Jon's reference to the lack of white paper. Anyways...

    AutoCAD XAttributes

    Yea, I am no expert here either. But looking at this oldish presentation on AutoCAD Plant 3d on spec and cat writing. It does look very similar to what OpenPlant is using for its own spec / catalog / schemas editors. It would make sense to see other CAD vendors having to have something similar. I recall that AutoCAD also introduced Entity Framework at the time. Don't hear much about it these days. Probably already decided to switch their bets onto Revit?

    You can want only what is defined in EC specifications

    No problems wit dat. Ones and zeros still have a lot of mileage left on the clock :-)

    Everything is else is not "EC", but just application layers and tools, build around EC world.

    Absolutely, but what I am interested in is how this can be developed with the best results for the user... not just the developers. As mentioned above, one of the big problems Mstn has is its lack of user-friendly data-centric tools... something that the competition has been able to capitalise on.

    So, what EC technology can do more for you? Nothing else than store data.

    Yea, this is the type of dev think that I am afraid of. You can be the data storing king of kings but it the user doesn't notice... well, then the writing is truly on the wall.

    based on EC successor (BIS schemas

    Ya, another thing that I am afraid of. Old hag Mstn being abandoned in favour of the new sexy girl in town? I guess nothing is forever. I would be interested to hear what BIS does better?

    when plenty of data - typically defining relationships, further conditions and abstract models - are not specific to particular element, but stored in model.

    Yea, its one thing to store the data in a type safe way, its a bigger problem to define and store links etc that propagate between them properly. Limits being  rehearsed by those guys trying to improve IFC and ISO 15926 etc for years. May not work at all.

    In many ways it is another reason to look more seriously at something 'dumber' like Item Types and UI-based automation tricks as described above.

    How about it, Jan? Do you think that something like expressions that are hosted in the Properties Panel that would work on general Mstn geometry will work? It suppose proof of concept has already been provided by OpenPlant. How would you do it, given your knowledge of the EC Framework APIs?

Reply
  • as often in your case, pretty long text, where I am not sure what is its intention: Is it question, complain, blog, a summary of personal ideas?

    HI Jan, its always good to hear from you... honestly!

    Length: Yes, I know. You should be getting used to it by now; The biggest clue is in the title : Whats in it for Mstn?

    I do not think "lots of confusion". Please, provide evidence.

    You correcting Jon goes a long way to answering your own question. See also Jon's reference to the lack of white paper. Anyways...

    AutoCAD XAttributes

    Yea, I am no expert here either. But looking at this oldish presentation on AutoCAD Plant 3d on spec and cat writing. It does look very similar to what OpenPlant is using for its own spec / catalog / schemas editors. It would make sense to see other CAD vendors having to have something similar. I recall that AutoCAD also introduced Entity Framework at the time. Don't hear much about it these days. Probably already decided to switch their bets onto Revit?

    You can want only what is defined in EC specifications

    No problems wit dat. Ones and zeros still have a lot of mileage left on the clock :-)

    Everything is else is not "EC", but just application layers and tools, build around EC world.

    Absolutely, but what I am interested in is how this can be developed with the best results for the user... not just the developers. As mentioned above, one of the big problems Mstn has is its lack of user-friendly data-centric tools... something that the competition has been able to capitalise on.

    So, what EC technology can do more for you? Nothing else than store data.

    Yea, this is the type of dev think that I am afraid of. You can be the data storing king of kings but it the user doesn't notice... well, then the writing is truly on the wall.

    based on EC successor (BIS schemas

    Ya, another thing that I am afraid of. Old hag Mstn being abandoned in favour of the new sexy girl in town? I guess nothing is forever. I would be interested to hear what BIS does better?

    when plenty of data - typically defining relationships, further conditions and abstract models - are not specific to particular element, but stored in model.

    Yea, its one thing to store the data in a type safe way, its a bigger problem to define and store links etc that propagate between them properly. Limits being  rehearsed by those guys trying to improve IFC and ISO 15926 etc for years. May not work at all.

    In many ways it is another reason to look more seriously at something 'dumber' like Item Types and UI-based automation tricks as described above.

    How about it, Jan? Do you think that something like expressions that are hosted in the Properties Panel that would work on general Mstn geometry will work? It suppose proof of concept has already been provided by OpenPlant. How would you do it, given your knowledge of the EC Framework APIs?

Children
No Data