[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [COAS-List] Potential Issue for the FTF
At 08:49 AM 6/17/99 -0700, Tim Brinson wrote:
>Hello COAS Team,
>
>
>See the attached email thread for a potential issue for the Finalization
>Task Force (FTF) that will be formed at the next OMG meeting. The COAS
>spec uses the kind of structure they talk about for the Observation Data
>type (I think that is the type it was used for but don't have the spec
>handy right now). I have uncovered a few other problems with the
>Observation Data type as well. I will explain them more after the FTF
>forms but here are some quick summaries:
>
> - It duplicates dyamic structuring functionality already
>standardized within the ORB (DynAny). This functionality was not
>implemented widely (since it was fairly new) 6 months ago but I have
>found it in many ORBS now. Why should we create a COAS specific
>capability that is already available inthe middleware? It was no
>
> - Out of three scenerios (observations with no structure, static
>structured observations, dynamic structured observations) it
>standardizes on the most expensive (dynamic structured). This does not
>allow as efficient implementation of structureless observations and it
>prevents using static structured observations at all. Using some
>alternatives would have little or no effect on dynamic structured
>observations. Besides as mentioned above the ORB can deal with dynamic
>structured data types via DynAny. The current structuring capability
>could still be specified as an option for those cases where DynAny is
>not available or where people have already implemented the spec but not
>be required.
From our discussions this week, I understand that you want to return an
Any instead of
an ObservationData or ObservationData sequence, and use DynAny to figure
out that it
is an ObservationData or some other simpler structure. I've looked at the
DynAny
specification, and it certainly looks useful, but I'm not sure how much
difference it makes here.
I think what you want is to have the ability to return "simpler" structures
(say without qualifiers),
but the advantage of this is not totaly clear to me. I don't see how the
current approach
prevents using static structured observations. These would be defined as
an ObservationValue (essentially and AtomicObservation). But isn't what
you are proposing the same as this?
It seems to me that we still need to understand the data that is coming
back whether it is coming back as
an Any or as an ObservationData[].
> - It breaks interoperability in a number of ways. To implement
>statically structured observations you have to put them in the
>AtomicObservation which breaks the semantics of the standard observation
>structure. As you know interoperability is not a global phenomena, it
>occurs within a domain (e.g. a country or a specific healthcare
>institution). You can not use the ORBs static binding capabilites to do
>compile time checking of allowed observation types within an
>interoperability domain.
I think we need to understand the implications of what you propose on the
COAS Information model to
really evaluate what you are proposing. It seems that you are extending the
definition of CompositeObservation.
This may be good but it seems to be a deviation from the COAS information
model. I need to see examples
of how you would use this capability.
> - It prevents usage in certain environments. By requiring dynamic
>structuring ownly (which can be a major expense) certain applications
>that could use COAS but require minimized footprint would not be able to
>use it.
It seems that the footprint would increase with by using the DynAny as it
adds to the types of data that
my client needs to handle.
> - By COAS (an RM-ODP Computaional Viewpoint specification) dictating
>particular rules of structuring within the IDL (ObservationData) it is
>not as independent of the RM-ODP Information Viewpoint as it could be.
>A particular Information Viewpoint standard (e.i. HL7 RIM and/or
>Templates, or UK-NHS models or Brazil data models for Observations)
>could have structuring rules that don't fit into the COAS rules. This
>would require an explicit mapping that could be costly (run time issue),
>complicated (design time issue) or maybe impossible. For example a
>single atomic observation is allowed within a composite observation but
>some information models might allow multiple. First it is not clear if
>they would be allowed in the COAS model but if they were you would have
>to create an additional level (fake level) of composite observation to
>deal with them.
I thought the COAS rules are very general. It seems that the only
limitation is
the requirement that there by a potentially empty array of
qualifiers. Otherwise
the data is simply a name,value pair in the simplest case and DynAny could be
used to extract the value.
>I see a VERY small change in the spec that could be correct these and
>still provide the functionality of the current ObservationData type. I
>will discuss this on the FTF.
I need to see the specific suggested changes to understand this better. I have
no problem with data coming back as an Any, but this may complicate the
data management.
Thanks,
Dave
>Regards,
>
>Tim Brinson
>
>
>Return-Path: <stiller@franz.com>
>Received: from celsus.mspring.net ([207.69.193.92])
> by mx9.mindspring.com (Mindspring Mail Service) with ESMTP id
> rme6ei.gfs.37kbi17
> for <tbrinson@mindspring.com>; Tue, 15 Jun 1999 23:28:17 -0400 (EDT)
>Received: (from root@localhost)
> by celsus.mspring.net (8.8.8/8.8.8) id XAA16695
> for tbrinson@mindspring.com; Tue, 15 Jun 1999 23:28:16 -0400 (EDT)
>Received: from emerald.omg.org (emerald.omg.org [192.67.184.65]) by
> celsus.mspring.net (8.8.8/8.8.8) with ESMTP id XAA16464; Tue,
> 15 Jun 1999 23:28:07 -0400 (EDT)
>Received: from turtle.franz.com (turtle.franz.com [192.132.95.23]) by
> emerald.omg.org (8.9.2/8.9.2) with ESMTP id XAA02785; Tue, 15
> Jun 1999
> 23:20:44 -0400 (EDT)
>Received: from corba.franz.com (corba [192.132.95.201]) by
> turtle.franz.com (8.9.1a/8.9.0) with SMTP id UAA14855; Tue, 15
> Jun 1999
> 20:10:23 -0700
>Received: by corba.franz.com (SMI-8.6/FI-2.0) id UAA11250; Tue,
> 15 Jun 1999 20:10:21 -0700
>Date: Tue, 15 Jun 1999 20:10:21 -0700
>Message-Id: <199906160310.UAA11250@corba.franz.com>
>From: Lewis Stiller <stiller@franz.com>
>To: interop@omg.org, orbos@omg.org
>Subject: GIOP encoding of IR operations
>X-Mozilla-Status2: 00000000
>MIME-Version: 1.0
>
>This issue is very old and very well-known, but I did not to see it
>addressed explicitly in the latest 2.3 drafts:
>
>Consider:
>
>module ex {struct foo {sequence<foo> bar;};}
>
>Suppose S is an object reference for instance of type CORBA::StructDef
>representing the struct ex::foo.
>
>What is returned on-the-wire when the value of the members attribute
>for S is requested over IIOP?
>
>Specifically, how is the type member, which is of type TypeCode, for
>the StructMember corresponding to the bar member of ex::foo,
>marshalled?
>
>However this is supposed to be marshalled, I recommend an explanation
>in the CDR section, since right now it sounds like recursive typecodes
>not in a top-level typecode cannot be marshalled portably.
>
>I think this issue would come up even more often with ValueDef.
>
>
>Return-Path: <jon@floorboard.com>
>Received: from celsus.mspring.net ([207.69.193.92])
> by mx7.mindspring.com (Mindspring Mail Service) with ESMTP id
> rmedms.o0d.37kbi15
> for <tbrinson@mindspring.com>; Wed, 16 Jun 1999 01:32:12 -0400 (EDT)
>Received: (from root@localhost)
> by celsus.mspring.net (8.8.8/8.8.8) id BAA04443
> for tbrinson@mindspring.com; Wed, 16 Jun 1999 01:32:11 -0400 (EDT)
>Received: from emerald.omg.org (emerald.omg.org [192.67.184.65]) by
> celsus.mspring.net (8.8.8/8.8.8) with ESMTP id BAA06224; Wed,
> 16 Jun 1999 01:32:06 -0400 (EDT)
>Received: from floorboard.com (corvette.floorboard.com [170.1.176.53]) by
> emerald.omg.org (8.9.2/8.9.2) with SMTP id BAA14162; Wed, 16
> Jun 1999
> 01:28:11 -0400 (EDT)
>Received: from floorboard.com by floorboard.com (SMI-8.6/SMI-SVR4) id
> WAA23904; Tue, 15 Jun 1999 22:14:38 -0700
>Sender: jon@floorboard.com
>Message-Id: <376732BE.F6FACD90@floorboard.com>
>Date: Tue, 15 Jun 1999 22:14:38 -0700
>From: Jonathan Biggar <jon@floorboard.com>
>X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m)
>X-Accept-Language: en
>Mime-Version: 1.0
>To: Lewis Stiller <stiller@franz.com>
>Cc: interop@omg.org, orbos@omg.org
>Subject: Re: GIOP encoding of IR operations
>References: <199906160310.UAA11250@corba.franz.com>
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>X-Mozilla-Status2: 00000000
>
>Lewis Stiller wrote:
> >
> > This issue is very old and very well-known, but I did not to see it
> > addressed explicitly in the latest 2.3 drafts:
> >
> > Consider:
> >
> > module ex {struct foo {sequence<foo> bar;};}
> >
> > Suppose S is an object reference for instance of type CORBA::StructDef
> > representing the struct ex::foo.
> >
> > What is returned on-the-wire when the value of the members attribute
> > for S is requested over IIOP?
> >
> > Specifically, how is the type member, which is of type TypeCode, for
> > the StructMember corresponding to the bar member of ex::foo,
> > marshalled?
> >
> > However this is supposed to be marshalled, I recommend an explanation
> > in the CDR section, since right now it sounds like recursive typecodes
> > not in a top-level typecode cannot be marshalled portably.
> >
> > I think this issue would come up even more often with ValueDef.
>
>Here is how I think it can be marshalled (structurally):
>
>(Level 1 TypeCode)
>kind: sequence
>length: 0
>content_type: (Level 2 TypeCode)
> kind: struct
> id: "IDL:ex/foo:1.0"
> name: "foo"
> member_count: 1
> member_name[0]: "bar";
> member_type[0]: (Level 3 TypeCode indirect to Level 1)
>
>Now some may argue that CDR typecode indirection cannot occur here, and
>should only occur directly inside a sequence (or valuetype) typecode,
>but I see no such restriction in the standard.
>
>There are also a number of less compact ways of marshalling it, by
>unrolling the recursion as many times as you like.
>
>--
>Jon Biggar
>Floorboard Software
>jon@floorboard.com
>jon@biggar.org
>Return-Path: <michi@triodia.com>
>Received: from tacitus.mspring.net ([207.69.193.96])
> by mx7.mindspring.com (Mindspring Mail Service) with ESMTP id
> rmeig1.5a4.37kbi15
> for <tbrinson@mindspring.com>; Wed, 16 Jun 1999 02:53:53 -0400 (EDT)
>Received: (from root@localhost)
> by tacitus.mspring.net (8.8.8/8.8.8) id CAA05344
> for tbrinson@mindspring.com; Wed, 16 Jun 1999 02:53:53 -0400 (EDT)
>Received: from emerald.omg.org (emerald.omg.org [192.67.184.65]) by
> tacitus.mspring.net (8.8.8/8.8.8) with ESMTP id CAA29345; Wed,
> 16 Jun 1999 02:53:51 -0400 (EDT)
>Received: from styx.triodia.com (root@styx.triodia.com [210.8.155.225]) by
> emerald.omg.org (8.9.2/8.9.2) with ESMTP id CAA15347; Wed, 16
> Jun 1999
> 02:50:02 -0400 (EDT)
>Received: from bobo.triodia.com (michi@bobo.triodia.com [210.8.155.226])
> by styx.triodia.com (8.9.1/8.9.1) with ESMTP id QAA26091; Wed,
> 16 Jun 1999 16:34:32 +1000
>Date: Wed, 16 Jun 1999 16:33:21 +1000 (EST)
>From: Michi Henning <michi@triodia.com>
>To: Jonathan Biggar <jon@floorboard.com>
>Cc: Lewis Stiller <stiller@franz.com>, interop@omg.org, orbos@omg.org
>Subject: Re: GIOP encoding of IR operations
>In-Reply-To: <376732BE.F6FACD90@floorboard.com>
>Message-Id: <Pine.HPX.4.05.9906161632370.24123-100000@bobo.triodia.com>
>Organization: Triodia Technologies
>Mime-Version: 1.0
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>X-Mozilla-Status2: 00000000
>
>On Tue, 15 Jun 1999, Jonathan Biggar wrote:
>
> > Here is how I think it can be marshalled (structurally):
>
>I agree, and we should nail this down. For the next revision, I hope
>to get rid of these silly anonymous types once and for all, so we won't
>have this and many other headaches anymore...
>
> Cheers,
>
> Michi.
>--
>Michi Henning +61 7 3236 1633
>Triodia Technologies +61 4 1118 2700 (mobile)
>PO Box 372 +61 7 3211 0047 (fax)
>Annerley 4103 michi@triodia.com
>AUSTRALIA http://www.triodia.com/staff/michi-henning.html
>
>Return-Path: <janssen@parc.xerox.com>
>Received: from tacitus.mspring.net ([207.69.193.96])
> by mx7.mindspring.com (Mindspring Mail Service) with ESMTP id
> rmeo6f.ts1.37kbi15
> for <tbrinson@mindspring.com>; Wed, 16 Jun 1999 04:31:11 -0400 (EDT)
>Received: (from root@localhost)
> by tacitus.mspring.net (8.8.8/8.8.8) id EAA09374
> for tbrinson@mindspring.com; Wed, 16 Jun 1999 04:31:11 -0400 (EDT)
>Received: from emerald.omg.org (emerald.omg.org [192.67.184.65]) by
> tacitus.mspring.net (8.8.8/8.8.8) with ESMTP id EAA23828; Wed,
> 16 Jun 1999 04:31:05 -0400 (EDT)
>Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM
> [13.1.64.93]) by emerald.omg.org (8.9.2/8.9.2) with SMTP id
> DAA15897;
> Wed, 16 Jun 1999 03:14:36 -0400 (EDT)
>Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com
> with SMTP id <55721(5)>; Wed, 16 Jun 1999 00:03:56 PDT
>Received: by holmes.parc.xerox.com id <16144>; Wed, 16 Jun 1999 00:03:38 PDT
>Received: from
> Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
> via MS.5.6.holmes.parc.xerox.com.sun4_41; Wed, 16 Jun 1999
> 00:03:38 -0700 (PDT)
>Message-Id: <MrNol_0B0KGWJ9Og0D@holmes.parc.xerox.com>
>Date: Wed, 16 Jun 1999 00:03:38 PDT
>Sender: Bill Janssen <janssen@parc.xerox.com>
>From: Bill Janssen <janssen@parc.xerox.com>
>To: Jonathan Biggar <jon@floorboard.com>, Michi Henning <michi@triodia.com>
>Subject: Re: GIOP encoding of IR operations
>Cc: Lewis Stiller <stiller@franz.com>, interop@omg.org, orbos@omg.org
>In-Reply-To: <Pine.HPX.4.05.9906161632370.24123-100000@bobo.triodia.com>
>References: <Pine.HPX.4.05.9906161632370.24123-100000@bobo.triodia.com>
>X-Mozilla-Status2: 00000000
>MIME-Version: 1.0
>
>Excerpts from local.omg: 15-Jun-99 Re: GIOP encoding of IR ope.. Michi
>Henning@triodia.co (598*)
>
> > I hope
> > to get rid of these silly anonymous types once and for all, so we won't
> > have this and many other headaches anymore...
>
>Hear, hear!
>
>Bill
>Return-Path: <jam@paragon-software.com>
>Received: from tacitus.mspring.net ([207.69.193.96])
> by mx6.mindspring.com (Mindspring Mail Service) with ESMTP id
> rmel37.u5i.37kbi14
> for <tbrinson@mindspring.com>; Wed, 16 Jun 1999 03:38:15 -0400 (EDT)
>Received: (from root@localhost)
> by tacitus.mspring.net (8.8.8/8.8.8) id DAA25674
> for tbrinson@mindspring.com; Wed, 16 Jun 1999 03:38:15 -0400 (EDT)
>From: jam@paragon-software.com
>Received: from emerald.omg.org (emerald.omg.org [192.67.184.65]) by
> tacitus.mspring.net (8.8.8/8.8.8) with ESMTP id DAA29630; Wed,
> 16 Jun 1999 03:38:13 -0400 (EDT)
>Received: from drudge1.camros.com (drudge1.paragon-software.com
> [204.91.29.4]) by emerald.omg.org (8.9.2/8.9.2) with SMTP id
> DAA28580 for
> <orbos@omg.org>; Wed, 16 Jun 1999 03:33:41 -0400 (EDT)
>Received: (qmail 765 invoked from network); 16 Jun 1999 07:19:19 -0000
>Received: from grub.paragon-software.com (204.91.29.200) by
> drudge1.paragon-software.com with SMTP; 16 Jun 1999 07:19:19 -0000
>Received: (qmail 17882 invoked by uid 501); 16 Jun 1999 07:19:20 -0000
>Message-Id: <19990616071920.17881.qmail@grub.paragon-software.com>
>Subject: Re: GIOP encoding of IR operations
>To: jon@floorboard.com (Jonathan Biggar)
>Date: Wed, 16 Jun 1999 03:19:20 -0400 (EDT)
>Cc: stiller@franz.com, interop@omg.org, orbos@omg.org
>Reply-To: jam@camros.com
>In-Reply-To: <376732BE.F6FACD90@floorboard.com> from "Jonathan Biggar" at
> Jun 15, 99 10:14:38 pm
>X-Mailer: ELM [version 2.4 PL25]
>Mime-Version: 1.0
>Content-Type: text/plain; charset=US-ASCII
>Content-Transfer-Encoding: 7bit
>X-Mozilla-Status2: 00000000
>
>
>This brings up an related issue:
> Many vendors seem to have disagreements about what the indirection
> actually points to: does is it always indirect to a 4 byte boundry?
>
> The spec doesn't say anything directly other than that the indirection
> always points to the "tk_kind" value of the encoded type code (although
> there is a reference saying that the byte order of the referencecd
> type code can be determined by the tk_kind value at that location).
>
> I believe the indirection should always point to a four byte boundry, but
> it is simple enough to always round up.
>
> Some vendors think agree, others do not (and some products perform
> differently depending on the language binding & version used - no names
> mentioned).
>
> Some implementations throw a MARSHAL if the indireection is rounded, some
> throw if it is not (uh interoperability?).
>
> I'm sure this will become more of an issue once we start to get more OBV
> implementations, where indirections are used quite often and the spec has
> the same clarity problem.
>
>Maybe this should be clarified...
>
>-jeff
>
> >
> > Lewis Stiller wrote:
> > >
> > > This issue is very old and very well-known, but I did not to see it
> > > addressed explicitly in the latest 2.3 drafts:
> > >
> > > Consider:
> > >
> > > module ex {struct foo {sequence<foo> bar;};}
> > >
> > > Suppose S is an object reference for instance of type CORBA::StructDef
> > > representing the struct ex::foo.
> > >
> > > What is returned on-the-wire when the value of the members attribute
> > > for S is requested over IIOP?
> > >
> > > Specifically, how is the type member, which is of type TypeCode, for
> > > the StructMember corresponding to the bar member of ex::foo,
> > > marshalled?
> > >
> > > However this is supposed to be marshalled, I recommend an explanation
> > > in the CDR section, since right now it sounds like recursive typecodes
> > > not in a top-level typecode cannot be marshalled portably.
> > >
> > > I think this issue would come up even more often with ValueDef.
> >
> > Here is how I think it can be marshalled (structurally):
> >
> > (Level 1 TypeCode)
> > kind: sequence
> > length: 0
> > content_type: (Level 2 TypeCode)
> > kind: struct
> > id: "IDL:ex/foo:1.0"
> > name: "foo"
> > member_count: 1
> > member_name[0]: "bar";
> > member_type[0]: (Level 3 TypeCode indirect to Level 1)
> >
> > Now some may argue that CDR typecode indirection cannot occur here, and
> > should only occur directly inside a sequence (or valuetype) typecode,
> > but I see no such restriction in the standard.
> >
> > There are also a number of less compact ways of marshalling it, by
> > unrolling the recursion as many times as you like.
> >
> > --
> > Jon Biggar
> > Floorboard Software
> > jon@floorboard.com
> > jon@biggar.org
> >