Issue 2211: The term name-value pair is not well defined (notif_service-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: 1) The term name-value pair is not well defined in the Notification document. Suggested resolution: We need to decide as a group to explicitly state that either only CosNotification::PropertySeq is supported (as well as structutally equivalent types only when IIOP messages elide member naming or IR info), OR that any structurally equivalent type is supported. I would favour the former - as it allows implementers to rely on the TypeCode::equal() operation to do comparisons portably rather than doing explicit traversals of the typecode. Resolution: Added text to 2nd paragraph of section 2.5.2 Revised Text: Actions taken: November 16, 1998: received issue November 16, 1999: closed issue Discussion: Synopsis: DSTC feels that the term "name-value pair" is used too freely throughout the spec without a clear definition of what's meant by it. They suggested that we should either explicitly state that either CosNotification::PropertySeq must be used wherever a name-value pair is called for (except where IIOP messages elide member naming or IR info, in which case structurally equivalent types may be used instead), or that any structurally equivalent type can always be substituted for a CosNotification::PropertySeq. DSTC mentioned that their preference is the former, as it allows for explicit, portable type comparisons rather than requiring typecode traversal to do type checking. Disposition: I have no objection to DSTC's first proposed resolution, except that I do not understand the parenthetical part, which I abstracted from DSTC's original mail describing the issue to make sure it wasn't dropped, even though I don't understand it. Essentially, I feel DSTC wants Notification to explicitly state the name-value pairs used throughout Notification must always be the data type CosNotification::PropertySeq, and not some structural equivalent, except in one exception case which I'm not quite clear about. Once DSTC clarifies this last part, I would be happy to incorporate the suggested change. VOTE: YES means to add text clarifying that name-value pairs in Notification are always of type CosNotification::PropertySeq; NO means to do nothing End of Annotations:===== Return-Path: To: issues@omg.org Cc: notif_service-rtf@omg.org, Mark Spruiell Errors-to: devnull@dstc.edu.au Reply-to: notif_service-rtf@omg.org Subject: 3 more Notification constraint language issues X-face: *A\_v+D,~Jx_g]`m,s61-x|*;H4hgZeE= Hi all, Here are 3 more Notification Service issues that Mark Spruiell from OOC and I have dug up. 1) The term name-value pair is not well defined in the Notification document. Suggested resolution: We need to decide as a group to explicitly state that either only CosNotification::PropertySeq is supported (as well as structutally equivalent types only when IIOP messages elide member naming or IR info), OR that any structurally equivalent type is supported. I would favour the former - as it allows implementers to rely on the TypeCode::equal() operation to do comparisons portably rather than doing explicit traversals of the typecode. Return-Path: Sender: dchang@austin.ibm.com Date: Mon, 16 Nov 1998 10:10:35 -0600 From: David Chang To: notif_service-rtf@omg.org Cc: issues@omg.org, Mark Spruiell Subject: Re: 3 more Notification constraint language issues References: <199811160205.MAA07062@piglet.dstc.edu.au> Keith, My comments to your suggestion is attached to your note. David Chang Keith Duddy wrote: > > Hi all, > > Here are 3 more Notification Service issues that Mark Spruiell from > OOC and I have dug up. > > 1) The term name-value pair is not well defined in the Notification > document. > > Suggested resolution: > > We need to decide as a group to explicitly state that either only > CosNotification::PropertySeq is supported (as well as structutally > equivalent types only when IIOP messages elide member naming or IR > info), OR that any structurally equivalent type is supported. > I would favour the former - as it allows implementers to rely on the > TypeCode::equal() operation to do comparisons portably rather > than doing explicit traversals of the typecode. >> I favour only CosNotification::PropertySeq is supported. > > 2) I note that a footnote on page 34 of the spec says that the term > "name-value pair" is not meant to denote CORBA::NVList, but it > doesn't > actually say what it does mean. This should be fixed too (before > table > 2.2 where it's used first). > > Suggested resolution: > > As above - the footnote should state that the term "name-value pair" > refers to CosNotification::PropertySeq. >> Agree > > 3) The section 2.4.5 - "A Short-hand Notation for Filtering > a Generic Event" is supposed to provide a way of addressing all > event > types, IMO including typed event transmissions that appear within an > Any as a CosNotification::PropertySeq with properties for the > operation name and each parameter. > > Suggested resolution: > > Some text should be included which states that $ matches not > only $. for anys, but also $() in the case where the > any > contains a single CosNotification::PropertySeq. Agree > > K > -- > > ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: > Keith Duddy : dud at dstc.edu.au : > http://www.dstc.edu.au/AU/staff/dud > CRC for Distributed Systems Technology (DSTC) > General Purpose South, University of Queensland, 4072, Australia > ph: +61 7 336 5 4310 :: fx: +61 7 336 5 4311 > > ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: > 2nd edition of my book ``Java Programming with CORBA'' now in > bookshops > >>> http://www.wiley.com/compbooks/vogel <<< > > :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::