Issue 3102: marshalling of null values unclear (interop) Source: Micro Focus (Dr. Jishnu Mukerji, jishnu(at)microfocus.com) Nature: Uncategorized Issue Severity: Summary: Description: Instruction for marshalling of null values is missing (in ptc/99-03-07). Issues include: - The null_tag token is included in the grammar, but it's purpose is described nowhere. If this is the intended encoding of any null value, how are the typing semantics of values to be maintained? For example, which type-specific factory is to be used to create the null value to be passed to the servant? How are the truncation semantics to be preserved? - There is a statement in 15.3.4.5 that "[t]he tag value 0 is reserved for future use". Does this refer to null_tag? (Note that there seems to be inconsistent use of "tag" within the text.) If so, how are null values to be marshalled? The grammar doesn't seem to allow for zero length value_data. Resolution: to close with revision Revised Text: Add new section after current 15.3.4.3: " 15.3.4.4 Null Values All value types have a distinguished "null". All null values are encoded by the <null_tag> (0x0). The CDR encoding of null values includes no type information. " In 15.3.4.5, change the following paragraph: " The end tag is a negative long whose value is the negation of the absolute nesting depth of the value type ending at this point in the CDR stream. Any value types that have not already been ended and whose nesting depth is greater than the depth indicated by the end tag are also implicitly ended. The tag value 0 is reserved for future use (e.g., supporting a nesting depth of more than 2^31). The outermost value type will always be terminated by an end tag with a value of -1. " to: " The end tag is a negative long whose value is the negation of the absolute nesting depth of the value type ending at this point in the CDR stream. Any value types that have not already been ended and whose nesting depth is greater than the depth indicated by the end tag are also implicitly ended. An end tag value of 0 is reserved for future use (e.g., supporting a nesting depth of more than 2^31). The outermost value type will always be terminated by an end tag with a value of -1. " Actions taken: December 10, 1999: received issue October 4, 2000: closed issue Discussion: End of Annotations:===== Sender: jis@fpk.hp.com Message-ID: <38503DD0.B363458D@fpk.hp.com> Date: Thu, 09 Dec 1999 18:40:00 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.10.10 9000/777) MIME-Version: 1.0 To: issues@omg.org, interop@omg.org Subject: Found hidden in issue 2817 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 3kKe9TUF!!!J5e9TWM!! I discovered this issue hiding inside Core issue 2817 which may be of interest to the Interop RTF. If this has not already been assigned another issue number perhaps it should be given one. Orogiginal isse is from Victor Giddings: 2) Summary: marshalling of null values unclear Suggested assignment: interop RTF Description: Instruction for marshalling of null values is missing (in ptc/99-03-07). Issues include: - The null_tag token is included in the grammar, but it's purpose is described nowhere. If this is the intended encoding of any null value, how are the typing semantics of values to be maintained? For example, which type-specific factory is to be used to create the null value to be passed to the servant? How are the truncation semantics to be preserved? - There is a statement in 15.3.4.5 that "[t]he tag value 0 is reserved for future use". Does this refer to null_tag? (Note that there seems to be inconsistent use of "tag" within the text.) If so, how are null values to be marshalled? The grammar doesn't seem to allow for zero length value_data. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. X-Sender: giddiv@gamma Message-Id: Mime-Version: 1.0 Date: Sun, 19 Mar 2000 04:28:30 -0400 To: interop@omg.org From: Victor Giddings Subject: Proposed resolution for 3102 (Null Value Encoding) Content-Type: text/plain; charset="us-ascii" X-UIDL: [VE!!G~Sd9DEOd9R+8e9 Add new section after current 15.3.4.3: 15.3.4.4 Null Values All value types have a distinguished "null". All null values are encoded by the (0x0). The CDR encoding of null values includes no type information. In 15.3.4.5, change the following paragraph: * The end tag is a negative long whose value is the negation of the absolute nesting depth of the value type ending at this point in the CDR stream. Any value types that have not already been ended and whose nesting depth is greater than the depth indicated by the end tag are also implicitly ended. The tag value 0 is reserved for future use (e.g., supporting a nesting depth of more than 2^31). The outermost value type will always be terminated by an end tag with a value of -1. to: * The end tag is a negative long whose value is the negation of the absolute nesting depth of the value type ending at this point in the CDR stream. Any value types that have not already been ended and whose nesting depth is greater than the depth indicated by the end tag are also implicitly ended. An end tag value of 0 is reserved for future use (e.g., supporting a nesting depth of more than 2^31). The outermost value type will always be terminated by an end tag with a value of -1. Victor Giddings victor.giddings@ois.com Senior Product Engineer Objective Interface Systems 703-295-6500 1892 Preston White Drive Fax: 703-295-6501 Reston, VA 22091-5448 From: Paul Kyzivat To: interop@omg.org Subject: RE: Proposed resolution for 3102 (Null Value Encoding) Date: Mon, 20 Mar 2000 09:34:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ? -----Original Message----- > From: Victor Giddings [mailto:victor.giddings@ois.com] > Sent: Sunday, March 19, 2000 3:29 AM > To: interop@omg.org > Subject: Proposed resolution for 3102 (Null Value Encoding) > > > Add new section after current 15.3.4.3: > > 15.3.4.4 Null Values > > All value types have a distinguished "null". All null values > are encoded by > the (0x0). The CDR encoding of null values includes no > type > information. > > In 15.3.4.5, change the following paragraph: > > * The end tag is a negative long whose value is the negation of the > absolute nesting depth of the value type ending at this point > in the CDR > stream. Any value types that have not already been ended and > whose nesting > depth is greater than the depth indicated by the end tag are also > implicitly ended. The tag value 0 is reserved for future use (e.g., > supporting a nesting depth of more than 2^31). The outermost > value type > will always be terminated by an end tag with a value of -1. > > to: > > * The end tag is a negative long whose value is the negation of the > absolute nesting depth of the value type ending at this point > in the CDR > stream. Any value types that have not already been ended and > whose nesting > depth is greater than the depth indicated by the end tag are also > implicitly ended. An end tag value of 0 is reserved for > future use (e.g., > supporting a nesting depth of more than 2^31). The outermost > value type > will always be terminated by an end tag with a value of -1. > > > Victor Giddings victor.giddings@ois.com > Senior Product Engineer Objective Interface Systems > 703-295-6500 1892 Preston White Drive > Fax: 703-295-6501 Reston, VA 22091-5448 > >