new conformance classes and the Naming Service
-
Key: COAS-1
-
Legacy Issue Number: 3119
-
Status: open
-
Source: Philips Electronics ( Charles Carman)
-
Summary:
In editing the COAS specification to include the resolved solutions for the various issues I have come across the following problem with regard to the Naming Service:
The revised COAS now has three independent conformance categories:
1) interface conformance, i.e. the set of interfaces implemented by the server,
2) data structure conformance, i.e. whether ObservationDataStruct is used, or some other solution, e.g. OBV
3) qualified code conformance, i.e. whether the COAS rules for creating qualified codes from HL7 were used, etc.The current text for relating COAS and the Naming Service has the COAS conformance class (note the singular noun) placed in the "kind" member of the CosNaming::NameComponent struct, which is defined as a "string".
Several solutions are possible:- define delimiters to be placed between the conformance categories in the "kind" string,
- define a hierarchy of COAS names, with a different category placed in the "kind" string at each level of the hierarchy,
- define a set of combination conformance class names that combine a common conformance class from each category, representing the set with a single name,
- ...
My preference is ??,
- while the third would be take the least effort right now, it provides the least extensibility and interoperability,
- the second would only require small additions to the section in the appendix that describes how COAS and Naming work together, but it places some fairly strong constraints on Naming hierarchies, possibly requiring a complex hierarchy and naming schemes
for servers that support multiple interface and qualified code conformance classes (which is likely). - the first may break other clients that use the naming service, or it may be the best solution of the three.
- ...
-
Reported: COAS 1.0b1 — Wed, 15 Dec 1999 05:00 GMT
-
Updated: Fri, 6 Mar 2015 20:58 GMT