Menu
▾
▴
openoss-devel
|
From: Craig G. (opennms) <cg...@op...> - 2012-08-15 19:09:04
|
Hi,
In the PM dependencies model we have to return to the problem of how do
we deal with association classes. It appears that we never satisfactory
resolved this issue in the past because we didn't need association
classes in our models. It is now returning to haunt us. I have looked
carefully at the generated XSD's and it is clear that the present
solution in the Soap generator does not work in a useful way. In the JVT
generated code I have an alternative solution but it does not match the
SOAP generator (see attached Java classes).
The PM Dependency model contains one association class called the
PerformanceIndicatorSpecRelationship.
This has one attribute; String relationshipType. This generates the
following XSD which has no reference to either end of the relationship.
<xsd:element name="performanceIndicatorSpecRelationship"
type="tns:PerformanceIndicatorSpecRelationship"/>
<xsd:complexType name="PerformanceIndicatorSpecRelationship">
<xsd:annotation>
<xsd:documentation>
<p>An association between two
PerformanceIndicatorSpecifications, such as one indicator derived from
another.</p>
<p>This association class is optional</p>
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="relationshipType" type="xsd:string"
minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>A categorization of the relationship, such as
derived from, composite/atomic, and so forth.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is optional</p>
<p>This attribute is AVC enabled</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
Similarly the generated PerformanceIndicatorSpecification entities which
are linked by this association class do not reference the association
class. In fact, it appears that the the association class between
PerformanceIndicatorSpecification entities is not generated at all.
<xsd:complexType name="PerformanceIndicatorSpecification">
<xsd:annotation>
<xsd:documentation>
<p>A measure of a specific aspect of the performance of an
entity, such as a lost packets or average jitter, defined for a
PeformanceSpecification that may trigger the creation of a
PerformanceConsequence.</p>
<p>This entity is optional</p>
<p>This entity is extendable</p>
<p>This entity does not generate Object Creation
notifications (NA)</p>
<p>This entity does not generate Object Deletion
notifications (NA)</p>
<p>This entity does not generate Object Discovery
notifications (NA)</p>
<p>This entity generates Attribute Value Change
notifications.</p>
</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="entity:EntityBase">
<xsd:sequence>
<xsd:element name="name" type="xsd:string" minOccurs="1"
maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>A word, term, or phrase by which a
PerformanceIndicatorSpecification is known and distinguished from other
PerformanceIndicatorSpecifications.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is mandatory</p>
<p>This attribute is AVC enabled</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="description" type="xsd:string"
minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>A narrative that explains in detail what the
PerformanceIndicatorSpecification is.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is optional</p>
<p>This attribute is AVC enabled</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="perspective" type="xsd:string"
minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>The point of view for the
PerformanceIndicatorSpecification, such as a single user instance or an
aggregation.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is optional</p>
<p>This attribute is AVC enabled</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="indicatorCategory" type="xsd:string"
minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>A grouping or set of
PerformanceIndicatorSpecifications that are classified together because
of common characteristics, such as technology specific, service
specific, or technology/service independent.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is optional</p>
<p>This attribute is AVC enabled</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="indicatorType"
type="perf:IndicatorType" minOccurs="1" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>A kind of value that the
PerformanceIndicator can take on, such as numeric, text, and so forth.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is mandatory</p>
<p>This attribute is AVC enabled</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="derivationAlgorithm"
type="xsd:string" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>A step-by-step procedure used to calculate
the value of the PerformanceIndicator.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is optional</p>
<p>This attribute is AVC enabled</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="derivationMethod" type="xsd:string"
minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>For simple calculations, the method used to
calculate the value of a PerformanceIndicator, such as average, minimum,
maximum, sum, and so forth.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is optional</p>
<p>This attribute is AVC enabled</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="collectionType"
type="perf:CollectionType" minOccurs="1" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>The type of the collection such as: gauge,
commulative, status inspection. Indicators can be produced using these
methods.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is mandatory</p>
<p>This attribute is AVC enabled</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="indicatorUnit" type="xsd:string"
minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>The unit by which the indicator is measured.
For example: seconds, KBs, rate per second, etc.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is optional</p>
<p>This attribute is AVC enabled</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="ArrayOfPerformanceIndicatorSpecification">
<xsd:sequence>
<xsd:element name="item"
type="tns:PerformanceIndicatorSpecification" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
In short, we are generating an XSD for an assocation class in the
model which is not referenced by any entity and which cannot be
retrieved across the interface which seems fairly useless.
So my question is;
What is the PerformanceIndicatorSpecRelationship for?
Should association classes actually be treated as Entities so that they
can be referenced through entity identifiers and be used for indirection
between A and Z end's ( that way when an association changes, it makes
sense to send an association value change event) .
Or or should they be treated a data types which are embedded in entities
and contain the entity identifier of the other end artefact. Whatever
the answer is, we aren't doing anything useful at the moment.
Please see the generated Java implementation attached for some ideas.
This is a blocking issue for completing the RI/CTK code for PM
Craig
|
|
From: Flauw, M. <Mar...@hp...> - 2012-08-20 12:05:07
|
Craig,
You are correct, the implementation is not correct.
The association class is mainly a way to add some attributes to an association, so handling it as a true entity is not the best choice in my view.
Today for associations, we create an attribute in the source class with EntityIdentifier datatype.
The PerformanceIndicatorSpecRelationship is a bit special as it associates a class with itself.
Now, if we assume an association class C between A and B, with 2 attributes c1 and c2.
In theory we would need 2 datatypes:
C_AEND and C_ZEND
C_AEND would contain a pointer to A (entity identifier) and c1 and c2
C_ZEND would contain a pointer to B (entity identifier) and c1 and c2
If the association is navigable in both directions, then A would contain an attribute of type C_ZEND and B would contain an attribute of type C_AEND
If there is only 1 direction for navigability (like A-> B), then A would contain an attribute of type C_ZEND and the datatype C_AEND won't be needed.
Question: given that in both cases the pointer will be an entity identifier, would it be possible to simplify and only create C containing an entity identifier + c1 +c2 and use C for the attributes present in A and/or B. This would make things simpler.
Best regards
Marc
-----Original Message-----
From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig Gallen (opennms)
Sent: Wednesday, August 15, 2012 9:09 PM
To: openoss-devel; Flauw, Marc; Xose Ramon Sousa Vazquez; Craig Gallen (OpenNMS); Pierre Gauthier
Subject: Question About Association Classes in PM Dependency model
Hi,
In the PM dependencies model we have to return to the problem of how do we deal with association classes. It appears that we never satisfactory resolved this issue in the past because we didn't need association classes in our models. It is now returning to haunt us. I have looked carefully at the generated XSD's and it is clear that the present solution in the Soap generator does not work in a useful way. In the JVT generated code I have an alternative solution but it does not match the SOAP generator (see attached Java classes).
The PM Dependency model contains one association class called the PerformanceIndicatorSpecRelationship.
This has one attribute; String relationshipType. This generates the following XSD which has no reference to either end of the relationship.
<xsd:element name="performanceIndicatorSpecRelationship"
type="tns:PerformanceIndicatorSpecRelationship"/>
<xsd:complexType name="PerformanceIndicatorSpecRelationship">
<xsd:annotation>
<xsd:documentation>
<p>An association between two PerformanceIndicatorSpecifications, such as one indicator derived from another.</p>
<p>This association class is optional</p>
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="relationshipType" type="xsd:string"
minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>A categorization of the relationship, such as derived from, composite/atomic, and so forth.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is optional</p>
<p>This attribute is AVC enabled</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
Similarly the generated PerformanceIndicatorSpecification entities which
are linked by this association class do not reference the association
class. In fact, it appears that the the association class between PerformanceIndicatorSpecification entities is not generated at all.
<xsd:complexType name="PerformanceIndicatorSpecification">
<xsd:annotation>
<xsd:documentation>
<p>A measure of a specific aspect of the performance of an entity, such as a lost packets or average jitter, defined for a PeformanceSpecification that may trigger the creation of a PerformanceConsequence.</p>
<p>This entity is optional</p>
<p>This entity is extendable</p>
<p>This entity does not generate Object Creation
notifications (NA)</p>
<p>This entity does not generate Object Deletion
notifications (NA)</p>
<p>This entity does not generate Object Discovery
notifications (NA)</p>
<p>This entity generates Attribute Value Change notifications.</p>
</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="entity:EntityBase">
<xsd:sequence>
<xsd:element name="name" type="xsd:string" minOccurs="1"
maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>A word, term, or phrase by which a PerformanceIndicatorSpecification is known and distinguished from other PerformanceIndicatorSpecifications.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is mandatory</p>
<p>This attribute is AVC enabled</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="description" type="xsd:string"
minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>A narrative that explains in detail what the PerformanceIndicatorSpecification is.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is optional</p>
<p>This attribute is AVC enabled</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="perspective" type="xsd:string"
minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>The point of view for the PerformanceIndicatorSpecification, such as a single user instance or an aggregation.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is optional</p>
<p>This attribute is AVC enabled</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="indicatorCategory" type="xsd:string"
minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>A grouping or set of PerformanceIndicatorSpecifications that are classified together because of common characteristics, such as technology specific, service specific, or technology/service independent.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is optional</p>
<p>This attribute is AVC enabled</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="indicatorType"
type="perf:IndicatorType" minOccurs="1" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>A kind of value that the PerformanceIndicator can take on, such as numeric, text, and so forth.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is mandatory</p>
<p>This attribute is AVC enabled</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="derivationAlgorithm"
type="xsd:string" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>A step-by-step procedure used to calculate the value of the PerformanceIndicator.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is optional</p>
<p>This attribute is AVC enabled</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="derivationMethod" type="xsd:string"
minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>For simple calculations, the method used to calculate the value of a PerformanceIndicator, such as average, minimum, maximum, sum, and so forth.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is optional</p>
<p>This attribute is AVC enabled</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="collectionType"
type="perf:CollectionType" minOccurs="1" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>The type of the collection such as: gauge, commulative, status inspection. Indicators can be produced using these methods.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is mandatory</p>
<p>This attribute is AVC enabled</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="indicatorUnit" type="xsd:string"
minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>The unit by which the indicator is measured.
For example: seconds, KBs, rate per second, etc.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is optional</p>
<p>This attribute is AVC enabled</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="ArrayOfPerformanceIndicatorSpecification">
<xsd:sequence>
<xsd:element name="item"
type="tns:PerformanceIndicatorSpecification" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
In short, we are generating an XSD for an assocation class in the model which is not referenced by any entity and which cannot be retrieved across the interface which seems fairly useless.
So my question is;
What is the PerformanceIndicatorSpecRelationship for?
Should association classes actually be treated as Entities so that they can be referenced through entity identifiers and be used for indirection between A and Z end's ( that way when an association changes, it makes sense to send an association value change event) .
Or or should they be treated a data types which are embedded in entities and contain the entity identifier of the other end artefact. Whatever the answer is, we aren't doing anything useful at the moment.
Please see the generated Java implementation attached for some ideas.
This is a blocking issue for completing the RI/CTK code for PM
Craig
|
|
From: Flauw, M. <Mar...@hp...> - 2012-09-10 06:27:46
|
Hi Craig,
No resolution up to my knowledge.
Best regards
Marc
-----Original Message-----
From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig Gallen
Sent: Monday, September 03, 2012 9:56 AM
To: Flauw, Marc; 'Craig Gallen (opennms)'; 'openoss-devel'; 'Xose Ramon Sousa Vazquez'; 'Pierre Gauthier'
Subject: RE: Question About Association Classes in PM Dependency model
Hi,
Sorry for not following this up. Have we settled on a resolution for association classes or will we live with the current shortcomings for the next PM release?
Cheers
-----Original Message-----
From: Flauw, Marc [mailto:Mar...@hp...]
Sent: 20 August 2012 13:03
To: Craig Gallen (opennms); openoss-devel; Xose Ramon Sousa Vazquez; Pierre Gauthier
Subject: RE: Question About Association Classes in PM Dependency model
Craig,
You are correct, the implementation is not correct.
The association class is mainly a way to add some attributes to an association, so handling it as a true entity is not the best choice in my view.
Today for associations, we create an attribute in the source class with EntityIdentifier datatype.
The PerformanceIndicatorSpecRelationship is a bit special as it associates a class with itself.
Now, if we assume an association class C between A and B, with 2 attributes
c1 and c2.
In theory we would need 2 datatypes:
C_AEND and C_ZEND
C_AEND would contain a pointer to A (entity identifier) and c1 and c2 C_ZEND would contain a pointer to B (entity identifier) and c1 and c2
If the association is navigable in both directions, then A would contain an attribute of type C_ZEND and B would contain an attribute of type C_AEND If there is only 1 direction for navigability (like A-> B), then A would contain an attribute of type C_ZEND and the datatype C_AEND won't be needed.
Question: given that in both cases the pointer will be an entity identifier, would it be possible to simplify and only create C containing an entity identifier + c1 +c2 and use C for the attributes present in A and/or B.
This would make things simpler.
Best regards
Marc
-----Original Message-----
From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig Gallen (opennms)
Sent: Wednesday, August 15, 2012 9:09 PM
To: openoss-devel; Flauw, Marc; Xose Ramon Sousa Vazquez; Craig Gallen (OpenNMS); Pierre Gauthier
Subject: Question About Association Classes in PM Dependency model
Hi,
In the PM dependencies model we have to return to the problem of how do we deal with association classes. It appears that we never satisfactory resolved this issue in the past because we didn't need association classes in our models. It is now returning to haunt us. I have looked carefully at the generated XSD's and it is clear that the present solution in the Soap generator does not work in a useful way. In the JVT generated code I have an alternative solution but it does not match the SOAP generator (see attached Java classes).
The PM Dependency model contains one association class called the PerformanceIndicatorSpecRelationship.
This has one attribute; String relationshipType. This generates the following XSD which has no reference to either end of the relationship.
<xsd:element name="performanceIndicatorSpecRelationship"
type="tns:PerformanceIndicatorSpecRelationship"/>
<xsd:complexType name="PerformanceIndicatorSpecRelationship">
<xsd:annotation>
<xsd:documentation>
<p>An association between two PerformanceIndicatorSpecifications, such as one indicator derived from another.</p>
<p>This association class is optional</p>
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="relationshipType" type="xsd:string"
minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>A categorization of the relationship, such as derived from, composite/atomic, and so forth.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is optional</p>
<p>This attribute is AVC enabled</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
Similarly the generated PerformanceIndicatorSpecification entities which
are linked by this association class do not reference the association
class. In fact, it appears that the the association class between PerformanceIndicatorSpecification entities is not generated at all.
<xsd:complexType name="PerformanceIndicatorSpecification">
<xsd:annotation>
<xsd:documentation>
<p>A measure of a specific aspect of the performance of an entity, such as a lost packets or average jitter, defined for a PeformanceSpecification that may trigger the creation of a PerformanceConsequence.</p>
<p>This entity is optional</p>
<p>This entity is extendable</p>
<p>This entity does not generate Object Creation
notifications (NA)</p>
<p>This entity does not generate Object Deletion
notifications (NA)</p>
<p>This entity does not generate Object Discovery
notifications (NA)</p>
<p>This entity generates Attribute Value Change notifications.</p>
</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="entity:EntityBase">
<xsd:sequence>
<xsd:element name="name" type="xsd:string" minOccurs="1"
maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>A word, term, or phrase by which a PerformanceIndicatorSpecification is known and distinguished from other PerformanceIndicatorSpecifications.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is mandatory</p>
<p>This attribute is AVC enabled</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="description" type="xsd:string"
minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>A narrative that explains in detail what the PerformanceIndicatorSpecification is.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is optional</p>
<p>This attribute is AVC enabled</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="perspective" type="xsd:string"
minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>The point of view for the PerformanceIndicatorSpecification, such as a single user instance or an aggregation.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is optional</p>
<p>This attribute is AVC enabled</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="indicatorCategory" type="xsd:string"
minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>A grouping or set of PerformanceIndicatorSpecifications that are classified together because of common characteristics, such as technology specific, service specific, or technology/service independent.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is optional</p>
<p>This attribute is AVC enabled</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="indicatorType"
type="perf:IndicatorType" minOccurs="1" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>A kind of value that the PerformanceIndicator can take on, such as numeric, text, and so forth.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is mandatory</p>
<p>This attribute is AVC enabled</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="derivationAlgorithm"
type="xsd:string" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>A step-by-step procedure used to calculate the value of the PerformanceIndicator.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is optional</p>
<p>This attribute is AVC enabled</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="derivationMethod" type="xsd:string"
minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>For simple calculations, the method used to calculate the value of a PerformanceIndicator, such as average, minimum, maximum, sum, and so forth.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is optional</p>
<p>This attribute is AVC enabled</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="collectionType"
type="perf:CollectionType" minOccurs="1" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>The type of the collection such as: gauge, commulative, status inspection. Indicators can be produced using these methods.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is mandatory</p>
<p>This attribute is AVC enabled</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="indicatorUnit" type="xsd:string"
minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>The unit by which the indicator is measured.
For example: seconds, KBs, rate per second, etc.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is optional</p>
<p>This attribute is AVC enabled</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="ArrayOfPerformanceIndicatorSpecification">
<xsd:sequence>
<xsd:element name="item"
type="tns:PerformanceIndicatorSpecification" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
In short, we are generating an XSD for an assocation class in the model which is not referenced by any entity and which cannot be retrieved across the interface which seems fairly useless.
So my question is;
What is the PerformanceIndicatorSpecRelationship for?
Should association classes actually be treated as Entities so that they can be referenced through entity identifiers and be used for indirection between A and Z end's ( that way when an association changes, it makes sense to send an association value change event) .
Or or should they be treated a data types which are embedded in entities and contain the entity identifier of the other end artefact. Whatever the answer is, we aren't doing anything useful at the moment.
Please see the generated Java implementation attached for some ideas.
This is a blocking issue for completing the RI/CTK code for PM
Craig
|
Thanks for helping keep SourceForge clean.
X