[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issues 79 & 88 comments
I want to comment on issues 79 and 88 with some experience from mapping CIM classes to WSRF-RP. The mapping created a resource properties document for each CIM class which included all of the properties for that class and all base classes. In this way an instance of a particular class was completely represented by the already defined resource properties document for the class. A typical example looks like the following: <MostDerivedPropertyDocument> <!-- most derived class properties --> <!-- second level derived class properties --> <!-- first derived class properties --> <!-- most base properties --> </MostDerivedPropertyDocument> The problem comes in when one of the base classes in the hierarchy needs to be changed. With the cut-and-paste method of "derivation" supported by WS-ResourceProperties, all resource property documents that extend a document representing a class that has a change in its properties will also need to be changed. The cut-and-paste requirement makes for a maintenance headache for this example. A change in the most-base resource property document could ripple through possibly 100 other resource property documents. This seems like an unrealistic burden on developers. The CIM model is nested fairly deeply, and it changes over time. Properties/operations might move to a base or derived class. Properties/operations might be deprecated and eventually removed - new properties/operations are added. I suggest that one step towards fixing this is to allow xsd extends when defining a type rather than require only cut-and-paste. We could even continue to make the requirement that GEDs need to be used to define properties. This reduces the resource properties documents that need to be changed to 1 plus the actual deployed interfaces. CIM allows only single inheritance, so the extends mechanism works great. I think that in cases where a deployed service exposes multiple interfaces, some of those interfaces are likely to be extended from base interfaces, and some are likely to be base interfaces themselves. Allowing a combination of extends and cut-and-paste allows these types of interfaces to be most-efficiently represented. Bryan
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]