OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrf message

[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]