| ceXML - an XML vocabulary for building and civil engineering: Master thesis | ||
|---|---|---|
| Prev | Chapter 6. Design of the vocabulary | Next |
A problem that has to be solved is how to select elements. There is a tree of builtobjects, in which there are names, functions, quantifications, etcetera. They themselves are stored separately to save time and effort. A certain function will probably be shared by a number of builtobjects. Also the builtobjects contain other builtobjects. So there has to be some mechanism of pointing towards other items.
For this, there are two feasible ways:
Use ID's to identify items. An ID is an unique number or text that is used to identify exactly one item. door id="abc123", for example.
Use the names associated with the items to identify them. This means that you identify a specific item by searching for an item of that type with the name "door", for instance.
The ID mechanism has the advantage of not being bound to a specific language. Using names to identify items has the disadvantage that there will very probably be multiple items with the same name. An ID can be used to select exactly one specific item without any inherent language problems. A language can be trusted, however, to be logical enough to ensure that two items with the same name are more or less similar. If a real problem persists, it is necessary to use an alternative word to describe the item. A large number of conflicts can be found, however, in the naming of quantifications. Depth can be, for instance, the depth of a lake (a vertical unit of measurement) or the depth of a window (a horizontal unit of measurement). This can be solved by using a more descriptive unit, like construction-height (instead of just height) to indicate the vertical dimension of a bridge, and clearance for the vertical dimension that indicates the room available for ships to pass underneath the bridge.
The ID mechanism has the disadvantage that you have to be very careful with the ID's you give to items. Whatever happens, a door item will still be found by looking for the item with the name "door". Nothing keeps an ID from changing if there are no fixed rules for handing out ID's. Especially when ID's are automatically generated by computer systems of various suppliers, there are severe problems.
Programmatically, there is no difference between searching for a item with a certain name and searching for an item with a certain ID. To avoid adding ID elements to the language, I choose to select items by looking at their names[1].
| [1] | Not using ID's is a choice for my prototype, not a choice I would necessarily make for the final eConstruct system. A well devised ID system, probably using reasonably descriptive text as ID, gives the system much more freedom regarding the names given to items. In a real-world system there will not be much enthusiasm for a programmatic restriction on names. But for my prototype, the name system doesn't pose any problems and is much easier than having to hand out ID's to all items and, more important, keeping them in sync. |