Issue 3119: new conformance classes and the Naming Service (coas-ftf) Source: Philips Electronics (Mr. Charles Carman, nobody) Nature: Uncategorized Issue Severity: 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. * ... Resolution: Revised Text: Actions taken: December 15, 1999: received issue Discussion: End of Annotations:===== From: charles.carman@philips.com To: , Cc: Subject: COAS FTF: new conformance classes and the Naming Service Message-ID: <0056910002916471000002L112*@MHS> Date: Wed, 15 Dec 1999 00:14:19 -0600 MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id BAA07676 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 12/15/99 00:16:13" X-UIDL: W-T!!)BZd9U&=e98HM!! Tim, Tom, et. al. 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. * ... I welcome any comments and contributions. BTW, we have a deadline to complete this by Friday, 17-Dec-1999. I appologize if this message arrives too late for you to contribute this time. Sincerely, Charles S. Carman Philips Medical Systems 2171 Landings Drive Mountain View, CA 94043 +1.650.426.2509 Reply-To: "Jon Farmer" From: "Jon Farmer" To: , , Cc: References: <0056910002916471000002L112*@MHS> Subject: Re: COAS FTF: new conformance classes and the Naming Service Date: Wed, 15 Dec 1999 11:42:03 -0500 Organization: Care Data Systems MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: Od@e9*o To: ; Cc: Sent: Wednesday, December 15, 1999 1:14 AM Subject: COAS FTF: new conformance classes and the Naming Service Tim, Tom, et. al. 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. * ... I welcome any comments and contributions. BTW, we have a deadline to complete this by Friday, 17-Dec-1999. I appologize if this message arrives too late for you to contribute this time. Sincerely, Charles S. Carman Philips Medical Systems 2171 Landings Drive Mountain View, CA 94043 +1.650.426.2509 Date: Fri, 17 Dec 1999 12:17:44 -0800 From: Tim Brinson Reply-To: TBrinson@2ab.com Organization: 2ab X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jon Farmer CC: charles.carman@philips.com, tcculpepper@mmm.com, coas-ftf@omg.org Subject: Re: COAS FTF: new conformance classes and the Naming Service References: <0056910002916471000002L112*@MHS> <005501bf471b$5291f710$951e85cd@toledolink.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ;l,!!^T0!!][ I think the elegance and flexibility of the first solution (define > delimiters to be placed between the conformance categories in the > "kind" > string) justifies the backwards potential breakage effects because > the spec > is still so young. The other alternatives would put the onus on us > to > maintain the combinatorial catagories or the hierarchy, and I think > we have > better value-add things to do. > > Jon > > ----- Original Message ----- > From: > To: ; > Cc: > Sent: Wednesday, December 15, 1999 1:14 AM > Subject: COAS FTF: new conformance classes and the Naming Service > > Tim, Tom, et. al. > > 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. > * ... > > I welcome any comments and contributions. > BTW, we have a deadline to complete this by Friday, 17-Dec-1999. I > appologize if this message arrives too late for you to contribute > this time. > > Sincerely, > > Charles S. Carman > Philips Medical Systems > 2171 Landings Drive > Mountain View, CA 94043 > +1.650.426.2509