changing XML files.

Reading this longish thread, I have the following questions:

1. Currently, there is no easy way to modify values for multiple components. 'Bulk editing' is possible for most of the architectural tools via the Modify Properties of Selected Elements (MPSE) tool, but not for the Structural tools for example. Will ABD provide much needed uniformity here?

2. Looks like the DGS can draw info from multiple databases, via a UDL look up at property level (defined in the Catalog Editor). When the property is extracted from the database, are all the other properties in the property set stored in the database also updated? Or just the one?

3. Example workflow has three parameters: 1.Type of medium (condensate, cold, warm water or steam) 2.Type of insulation 3.Size of pipe. Three degrees of freedom, but with contraints. The user would pick one, two or all three and there will need to be a means to propagate the constrained changes to the other parameters.This highlights the problem that DGS currently has: everything is a loose instance parameter with very few tools for typing or checks or constraints. It's sort of sold as being 'flexible' but does not scale and not really fit for the future.

The database can provide a property for the insulation type, but this would need to be propagated to the ObjectMaterial schema .xsd and the F+P for the correct symbology. How would you make the link? Insulation Part Name => F+P Part look up table would be the easiest, I suppose. Or should this an IF-THEN expresion to be evaluated? Stored as an expression in the xml file? Or should all scripting be done at a higher level in one place per item 5? But all of this would require manual mapping. Ideally, new properties and pick lists would be inserted/updated into the .xsd from the database or the F+P system.

It would be good to know what sequence things will update and how conflicts are dealt with? Again, best done at 'Data Manager' level?

4. What about nested or linked components? Say the pipe is supported by hangers that also need be insulated. Or an AHU that has several subcomponents in its assembly. You want to set things up so that their DGS properties get updated as well.

5. It sounds like the UDL look up process can be used to "list of available Part names, or even use an MRU (most recently used) to do the same and then pick from there" A bit more information about how this works would be good. Can the user insert a VBA into the process? A some point, I suspect something like the Bentley Data Manager  would be needed manage all those loose xmls (definitions, catalogs, catalog items, catalog filters, databases), manufacturers spreadsheets, IFC mappings, reports, item types etc etc). At the moment, there are too many tiers: 1.The data saved with the dgn (DG Explorer, MPSE) 2.The xmls in the dataset (Catalog Editor + Defintion Editor, DG Utilities) 3.The databases (MS Access etc).

Apparently, when a property is linked using a UDL, or 'driven' by another property being updated by the database, it locks up a lot of fields. The user shouldn't have to 'fool' the system using a 'blank' Catalog Item xml so that he can work 'out-of-spec'. It would be good to get a statement from development setting out what happens when and how to control things. Maybe the synch/propagation needs to be manual in the short term... and managed by a 'Data Manager' in future? Also, it would be good to be able to allow the user to tag the properties an 'overriden' so that the next update would undo what was intentionally set.

6. At the moment, the DGS set of tools is too fragmented. It forces the user to jump through too many tools/entry points when he needs to change something. The old assumption that formating will be done rarely and by a CAD Admin is flawed. I see a lot of users having to deal with all kinds of 'ad hoc' components and schemas all the time. The idea that most components will be pre-defined is flawed. Even BuildingSmart recognise that most of the real world building components are still to be formated in IFC and are only providing a starting point. I see a lot of schema info being included into models via importing components downloaded from somewhere else like Google Warehouse or other portals.

 If the user selects a component in the DG Explorer (say a wall A-G25111-WallsExternalBrick) he should be able to right-click on the row and be offered an option to jump to the corresponding Catalog Item in the Catalog Editor and from there to the Definition Editor. Both the CE and DE should also offer direct right-click access to an xml editor. ABD?

7. Naturally, we shouldn't forget about providing better links to the external database app (MS Access etc) as well, not just the xml text editor. Maybe something bi-directional like the SS6 Edit-in-Excel tool would be great?

8. Also need to think about how to import parameters for PCS' successor. The way the user has to manually re-type all the parameters defined in PCS is a real flaw productivity-wise. ABD 2.0?

Just saw this wiki entry in the Openplant forum. Pretty cool. No UDL files.

Surely, the long term plan for Aecosim is to dump DGS and go with EC Framework based tools like Openplant or Openroad's Feature Definitions.

It should make interoperability a lot easier and minimise coding/maintenance duplication and maximise any future investment.

bump... any improvements to help make looking up external databases easier on the road map?

Not that I'm aware of.  I don't think changing the way that external databases are linked is very high in priority given the many other requested features and enhancements.   

Not that I'm aware of.  I don't think changing the way that external databases are linked is very high in priority given the many other requested features and enhancements.