a few problems with IDL contexts:
1) On page 4-32, with have:
"CORBA::CTX_DELETE_DESCENDENTS deletes the indicated context
^^^^^^^^^^^
object and all of its descendent context objects, as well."
^^^^^^^^^^
The standard system exception BAD_PARAM is raised if there are one
or more child context objects and the CTX_DELETE_DESCENDENTS
^^^^^^^^^^^
flag was not set."
That's a bit embarrassing because the correct spelling is "descendants",
not "descendents".
2) For the get_values() operation, we have:
"Scope indicates the context object level at which to initiate the
search for the specified properties (e.g. "_USER", "_SYSTEM"). If
the property is not found at the indicated level, the search
continues up the context object tree until a match is found
or all context objects in the chain have been exhausted."
This does not say exactly how this is meant to work. I assume that
the idea is to start at the current context object, checking whether its
name matches the start_scope parameter. If it does, start the search here;
otherwise, go up a level and repeat. Once a context object has been found
with a matching name, then start looking for the properties and collect
them together, with lower level settings overriding higher level settings,
until either all property values have been determined or we run out of
context objects.
If this is the intended interpretation, the words in the spec are a long
way from actually expressing that...
3) Context objects have names. Those names are used to control the behavior
of get_values(). However, we have two problems:
- The top-level context object does not have a defined name, so
I can't specify its name for get_values().
- Once I've given a context object a name, I can't get it back out.
(Yet another case where I am forced to give identity to an object
only to be denied any opportunity of ever asking what that
identity is...)
4) For create_child(), what happens if I:
- specify a name that doesn't look like an IDL identifier?
- call create_child() twice with the same name on the same
parent context?
5) For delete_values(), what is the behavior if the specified property
does not exist?
6) For delete(), what is the minor code of the BAD_PARAM exception
if I don't set the CTX_DELETE_DSCENDENTS [sic] flag and the context
has child contexts?
7) For get_values(), what does it mean to "omit" the scope name? The only
way to omit it, as far as I can see, is to pass the empty string. If so,
that should be stated.
8) For get_values(), what exception is raised if the specified scope name
is not found?
9) get_values() and delete() accept a Flags parameter. It is not specified
how to not set a flag (only what it may be set to). Given that Flags
is an unsigned long, presumably I have to pass zero to indicate that a
flag is not set. However, this is not specified.
10) For get_values(), what is the minor code of the BAD_CONTEXT system
exception if a property isn't found? Why a BAD_CONTEXT exception? Why
an exception at all (instead of returning an empty sequence)?
11) For get_values(), it says:
The NO_MEMORY exception is raised if dynamic memory allocation fails.
This sentence is utterly redundant.
12) For get_values(), we have:
The values returned may be freed by a call to the list free operation.
What "list free operation"? There is no such operation on NVList.
There is CORBA::free, but that is specific to the C mapping.
13) For get_values(), we have:
"Scope indicates the context object level at which to initiate the
search for the specified properties (e.g. "_USER", "_SYSTEM")."
However, for create_child(), we have:
"Context object names follow the rules for OMG IDL identifiers."
"_USER" and "_SYSTEM" are not valid IDL identifiers (at least they were
not at the time this was written, and you can argue that they still are
not valid IDL identifiers because the underscore is stripped immediately
by the IDL compiler).
14) What happens if I call get_default_context() multiple times? Presumably,
I will get a reference to the same single context object?
15) In the first para of page 4-29, it says:
"... although a specified property may have no value associated
with it"
This would appear to be impossible. If the property itself exists,
it always has a value, namely a string. The closest thing to "no value"
would appear to be the empty string (or a property doesn't exist at all).
16) "An operation definition may contain a clause specifying those context
properties that may be of interest to a particular operation. These
context properties comprise the minimum set of properties that will
be propagated to the server's environment..."
So, what happens if I have
interface I
{
void op() context("C");
}
;
and no property "C" exists in the context object passed by the client?
Does this mean that the call will be made, but no property "C" will
be available to the server? (I don't think so, because that would
contradict the above words about "minimum set of properties that will
be propagated")
Or does it mean that the call will be made, but that the value of "C"
will be the empty string?
Or does it mean that the call will be refused because the caller has
not supplied the required properties? If so, what exception is be
raised?
17) "Context property names (which are strings) typically have the
form of an OMG IDL identifier, or a series of OMG IDL identifiers
separated by periods."
This is in conflict with the words about property name syntax elsewhere.
This is a total mess. One interface with six operations, and about a dozen
bugs. Impressive! 
That's because the resolution