The C2INav Model refers to a package defined by OARIS 1.1.
OARIS 2.0 is about to be published and there are 2.1 RTF & 3.0 FTF in progress.
There are many 'classes' in the model (because that's what is in the message) for Mnemonic, frequently with different values. Same probably true of Sample and others. It would be great if these structs in the messages and classes in the model were better reused so that we don't have two different items both called "Mnemonic".
This issue sort of harkens back to when we had things like "Required Fields" in each message in the model, with no relationship to each other.
In the already-approved C2MS11-45, we added DB Query Messages. However, this issue did not include a text description for each message, which is common for all other C2MS Messages.
Specifically, the new sections 8.14.1 and 8.14.2 need a description in order to be consistent with other C2MS Messages.
Additionally, some of the subsection headers, table and figure titles don't conform to usage in the remainder of the document.
In C2MS11-163 we adjusted the base set of TLM messages to better handle CCSDS information and to include APID/SCID where appropriate.
There are some related messages that needed to have been adjusted as well. This issue takes up where the already-approved 163 left off. Specifically, we need changes to:
These changes align these adjacent messages to the to TLM message set and include SCID where appropriate.
Some Message Subjects:
have Request ID as one of the Message Subject Miscellaneous Elements. However, the type of REQUEST-ID is now GUID.
We need to figure out how to resolve this in the document text and tables. An RFC 4122 GUID does comply with Subject Token String, but we should address this.
Replay Telemetry Data Request Message and Replay Telemetry Data Response Message sections use inconsistent naming for section headers tables and figures compared to all other sections of the document. For example:
"Replay Telemetry Data Request Diagram"
"Replay Telemetry Response Message Header"
These should be made to use the full name of the message, just like other sections in the document.
In Product Response Message, PROD-MSGS-TO-SEND field is an unsigned type, with a stated minimum "value" of 0+, but says in the description text the following:
A value of “-1” can be used to indicate “Unknown”.
Should probably find a different way to indicate unknown, such as not including this optional field in the message.
MVAL and AMVAL seem pretty close in most respects, but MVAL Response Message has many fields that are not present in AMVAL Response Message. Probably just need to do some analysis regarding comparative usages and fields to determine if it is correct as-is and if not, add the missing fields to AMVAL Resp.
The MVAL Response and MVAL Data messages both can contain individual MVALs. But in one, certain MVAL fields are required, while in other they are not. These need to be made consistent.
Note that this applies to AMVAL Response and AMVAL Data messages as well.
Throughout the document, we use APID and AP ID interchangeably. For consistency, we should reduce all these references to just APID.
Because many separate changes have been made in the [MESSAGE-TYPE] Message Additional Information Tables and in the [MESSAGE-TYPE] Message Contents (model) Figures, this issue seeks to consolidate all such changes together for final review. Changes here should be considered, therefore, to supersede all other C2MS 1.1 changes to the specific tables and figures enclosed in this issue.
All such tables/figures are in Chapter 8 PIM - Message Definitions.
In C2MS11-45, approved in Ballot #10, the C2MS11 RTF added two new DB Query messages to C2MS 1.1. However, late in the 1.1 cycle, it was determined that these new messages are inadequate at the present time and need significant rework. The decision was made by the author of the DB Query messages to remove these from 1.1 and resubmit updated versions in a later release (1.2).
Therefore this issue is intended to undo the effect of C2MS11-45, so that those changes are not included in 1.1.
Note related issue (that was added to capture some of, but not all, of the updates needed) C2MS11-212.
An attached word doc includes markup text that was intended to augment the previously-approved C2MS11-45. This is simply included to aid recreation of a resolution issue in the future 1.2.
Two other attachments contain the originally-approved text for the spec. These should all be combined and reworked.
Add the DBQUERY messages that were defined by NASA to the formal specification.
These messages are listed as being part of the OMG specification here:
https://software.nasa.gov/software/GSC-18536-1
"A Graphics User Interface (GUI) based desktop viewer for XML Telemetry and Command Exchange (XTCE) files which allows some editing of the various XTCE properties of that open file, and then allows saving the updated information back to file. It includes a Goddard Mission Services Evolution Center (GMSEC) GMSEC Search XTCE (GSX) connector to support some GMSEC/ (Command and Control Message Specification) C2MS Database Query (DBQUERY) messages to search for some XTCE information which is then sent over GMSEC bus to the initiator of the search request."
The various Navigation Data Messages are nearly identical. They should be consolidated into a hierarchy that defines a Navigation Data Message base class and then let the others derive from it for better model structure. The Tracking Data Message has a few extra fields. Otherwise, everything is identical across all messages except for some type values.
I thought about doing this when I was updating the model in 1.1, but would have also had to update the chapter text and didn't have time for all that in 1.1.
The purpose NUM-OF-PROD-SUBTYPE-SUBCATEGORIES in several messages is not clear and needs to be reviewed and either removed or expanded upon. Note that this is called NUM-OF-PRODUCT-SUBTYPES in C2MS 1.0, but the explanations are simply preserved from 1.0 into 1.1 where the field was renamed, so this issue persists. One interesting aspect of this is that these subtype subcategories are represented in the subject of the Product Message ME5 and ME6, and all other messages that have it refer to this Subject construct.
The Log Message in 1.0 is vague in the sense of what it is supposed to be used for. Is it an application-level log (similar to Log4j or is it an event alerting mechanism for ground and/or satellite events. It might be useful to split it into application logging vs ground or satellite alerting. Need to analyze its intended and current use to the extent possible and recommend a way forward that clearly demarcates event alerts from logging.
We have a number of cases where there is a listing of something, like Files in Product Message. Although Num-of-files is required, nothing in the file itself is required.
Should review these and decide if any of these are dependent, and therefore required for each File.
Note that this is true in many other cases, need to find them all and come up with a plan for each.
Already identified as an issue in C2MS11-187, and resolved in its resolution, we are clarifying the text in the Additional Information Tables regarding PROD-SUBTYPE. The text describing ME5 and ME6 in Table 8-154 Properties of the Miscellaneous Elements for the Product Message needs to be updated as well.
In the messages where it exists, mnemonic.n.sample.m.quality is of type Boolean, with False meaning Good Quality and True meaning Questionable Quality. This just seems wrong. Probably should be a U16 with 1 = good and 0 = questionable.
After discussion in the C2MS 1.1 RTF March, 2024, we decided to soften some of the language that was previously inserted as part of the C2MS11-43 resolution, since the shorthand method, though deprecated, is still allowed.
In Mnemonic Value Data Message and Archive Mnemonic Value Data Message, the MNEMONIC.n.STATUS is Optional. Need to consider if it should be required for each MNEMONIC in the data message.
Align Alarm Text/Colors with other SDTF Specs.
Include a listing in the document that correlates colors with codes.
As the final version of 1.1 is being prepared, there are some items that need revisiting from already-approved issues.
Summary: The COM/CORBA Part A spec states that user exceptions go after return values in one place, and before return values in another. (3.2.10.3 and 4.1.3.1)
Summary: (D)IForeignComplexType,(D)ICORBAStruct,(D)ICORBAUnion,(D)IForeignException,(D)ICORBAUserException should have standard UUIDs and UUID identifiers
Summary: There should be a standard ProgramId for the class which exposes D(I)CORBAAny
Summary: The VB cannt handle array out-parameters. Must use in-outs.
Summary: Section 4.1.12: DICORBAtypeCode::kind has one parameter of type TCKind. It should be of type CORBATCKind
Summary: This property should be removed because the INSTANCE_repositoryId property in IForeignComplexType provides this functionality
Summary: The return value type should be DICORBATypeCode*, not IDispatch. The return value of member_label should be a DICORBAAny* rather than VARIANT
Summary: Section number: 3.5.1.1, item 4 plus appropriate section of interaction translation
Problem: How to handle the sending of an empty RESULT and the reception of
such a component.
Proposed solution: Obviously no way to change the IDL from void. Need
something in the TC Repository for use by a gateway in deciding what to do.
Summary: There should be straight dispatch versions of DCORBAObject and DORBObject
>You write on page 18-51:
>In COM V2.0, interfaces can have single inheritance. However, as opposed to
>CORBA,
>there is a standard mechanism by which an object can have multiple interfaces
>(without
>an inheritance relationship between those interfaces) and by which clients can
>query
>for these at run-time. (It defines no common way to determine if two interface
>references refer to the same object, or to enumerate all the interfaces
>supported by an
>entity.)
>
>It's not right, that there's no common way to determine if two interface
>references refer to the same object. The IUnknown-Pointer of two different
>interfaces of the same object must be the same (object identity in COM).
Summary: Issue: 5
Section number: 3.5.1.1, item 3
Problem: We have mistakenly associated TcLinkedContext with the operation
which has the LINKED keyword rather than the actual linked operation, i.e., the
operations appearing following the LINKED keyword
Summary: I can"t find in the COM/CORBA spec parts A and B any mention of how to
deal with IDL identifiers that are keywords to the Microsoft "mktyplib" tool.
This tool mangles the following identifier (not necessarily a complete list) by
prepending them with "_":
"BSTR", "CALLCONV", "coclass", "CY",
"CURRENCY", "DATE", "DECIMAL", "DISPID", "DISPPARAMS",
"dual", "EXCEPINFO", "guid", "GUID",
"HRESULT", "importlib", "IDispatch",
"INTERFACEDATA", "IUnknown", "LCID",
"METHODDATA", "odl", "oleautomation",
"PARAMDATA", "properties", "propget", "propput", "retval",
"SAFEARRAY", "SAFEARRAYBOUND", "SCODE",
"VARIANT", "VARIANTARG", "VARIANT_BOOL",
"VARTYPE", "VARENUM"
As far as I can tell, the output of the "mktyplib" tool makes use
(directly or indirectly) of the regular C++ bindings, whose identifiers
are not mangled the same way. This makes it impossible to emit COM bindings
for IDL files that contain the above keywords.
The problem that I"m running into is in CosTrading IDL, where the identifier
"properties" is used.
There is currently no specification for fixed-point types in the COM/CORBA mapping. I'm interested in getting this changed: how can we proceed? better still, is this work already under way??
Summary: Change the layout of both bounded and unbounded sequences to be the same
Summary:
Summary: When mapping bounded sequences, should the Automation View accept as an in-parameter a Safearray whose upper bound is less than the maximum lenght of the mapped sequence?
Summary: The uuid for DForeignException has an extra 0. It should be E977F907-3B75-11cf-BBFC-444553540000
Summary: There should be a standard name for the Automation View interface.
Summary: I suggest that the automation chapter be changed to align with the architecture chapter
Summary: When translating a BSTR to a CORBA bounded string, boundary violations should cause the View to propagate DISP_E_OVERFLOW
Summary: "..maximum value of an Automation short" should read "..maximum value of a CORBA::UShort
Summary: The "retval" attribute should be removed from the second argument in both methods. MIDL does not have a retval attribute
Summary: Second to last paragraph of the section contains the term "CORBA proxy" which should be changed to Automation View Interface.
Summary: INSTANCE_Clone does not need an in-parameter to specify the instance to be cloned.
Summary: Problem: There is a general problem on how to specify sending an empty
Transaction PDU, such as an empty BEGIN, or an empty CONTINUE. "Empty"
means just the Transaction portion without ROS components. This problem has
to be addressed for sending an empty Transaction PDU from the CORBA side,
as well as what to do when such a PDU is received from the legacy domain.
Summary: If number of dimensions of an input SAFEARRAY does not match the mapped CORBA type, the Automation View should generate the HRESULT DISP_E_TYPEMISMATCH
Summary: Section number: 5
Problem: Shouldn’t this section really be called TC Service Interface because it
really provides an IDL version of Q.771? Note that this requires changing the
names of various interfaces by removing the word Pdu, which should be
reasonably simple.
Summary: Section number: 6.1
Problem: Should SIOP version number start with 1.2?
Proposed solution:
Rationale: This would allow a quick recognition of the highest GIOP version supported by
this version of SIOP.
Summary: Section number: 6
Problem: Could SIOP be changed to 7IOP, pronounced "seven-up"?
Proposed solution:
Rationale: The S in SIOP may be mistaken for Security.
Align SIOP definition with GIOP 1.3 of CORBA2.3.1.
Problem: SIOP is currently defined to carry GIOP messages with version 1.2
and lower.
Proposed Solution: Allow GIOP 1.3 messages to be transported.
Summary: Section number: 6.2.2
Problem: sccp_version should be changed to SIOP_version. Also the word
"agent" should be changed to "server."
There are security tags mentioned in the SIOP
document but no definition of how to use them is ever given.
While editing the changes from the Firewall RTF into Core Chapter 15 I noticed a
curious thing in the Firewall RTF report. It seems that the RTF chose to re-use
a PolicyType id for a new and different policy while obsoleting a published one.
The PolicyType Id in question is 37, which used to be BIDIRECTIONAL_POLICY_TYPE
associated with the structure BiDirPolicy::BidirectionalPolicy
and is now proposed to be BIDIRECTIONAL_INVOKE_POLICY associated with structure
BiDirPolicy::InvokeMode.
This appears to me to be a dangerous practice, since the fact that the published
standard may have been implemented by someone using the obsolete definition.
I would like to suggest that the recommendation of the Firewall RTF be modified
leaving the published policy type and policy as is with a note stating that it
is obsolete, and a new policy type id be allocated for
BIDIRECTIONAL_INVOKE_POLICY.
Summary: Several LifeCycle methods take a "key" argument, but do not clarify whether multiple NameComponents are allowed in a key, if ordering matters, etc.
Summary: The Externalization spec does not state how a stream implementation is to discover that a context exists when internalizing an object.
Summary: The standard stream data format does not define tags to be used to identify the beginning and end of a context.
Summary: The standard stream format should specify that it is portable across different ORBs and hardware, but not across streamable object implementations whch use different semantic content.
Summary: What happens when multiple calls are made to Stream::externalize() at the top level? Does the stream contain all those objects, and how does a client discover this?
Summary: If the ORB times out while LockSet::lock() is being called, how does the client know if the lock was granted or not?
Summary: If the ORB suffered a communication failure while LockSet::lock() is being called, how does the client know if the lock was granted or not?
Summary: In a non-transactional lock request, the lock identity is supposedly based on thread ID. How can the server code get the client thread ID when they may be on different machines?
Summary: It is not clear whether CosTransactions::Coordinator is responsible for freeing locks at the end of a transaction.
Summary: CosTransactions Coordinator does not have any IDL method to remember LockCoordinator. How does it know what Lock Coordinators should be informed to drop locks?
Summary: For a non-transactional client who wants to get a LockCoordinator, what input values should one use for the "which argument?
Summary: It seemed more useful for the concurrency service to be non-IDL, and just based on local thread identification.
Summary: When reading a stream, there is no way of telling where context (limited to calls to begin_context and end_context) end and a new one starts.. Resolved problem with new "tag-byte" 0xFF.
Summary: If CosGraphs::deep propagation value is encountered, is the Node"s related object supposed to get copied, too. What if LifeCycleObject delegates to CosCompoundLifeCycle::Operations?
Summary: The second pass of operation is to "cause the node and all of its roles" to be copied. How do you get related object of the NEW roles to be the New Node?
Summary: When Node::externalize_node is called, is node responsible for externalizing related object? What happens, if related object isn"t a CosStream::Streamable?
Summary: Role in new node are disconnected It"s role of read_graph to correctly establish new relationships. How is that accomplished?
Summary: When internalizing a relationships, how do the "shallow" nodes and roles get included?
Summary: The IDL for internalizing roles could be optimized to reduce the size of the externalized data as well as simplifying the implementation
Summary: In the specification, "Related lock sets" appears only in "create_related()" and create_transaction_related()" Where do I use these methods
Summary: I assume that we are allowed to scope membership in a collection via an interface test (e.g, must be rooted off of Collection) and throw an InvalidElement exception?
Summary: Using collection factories, can you add multiple elements at once, and/or add new create methods?
Summary: On CollectionObj->remove_element_at(IteratorRef), how does the collection "know" the index?
Summary: How do IteratorObjs and CollectionObjs share state?
Summary: What does the IteratorPositionInvalid exception mean? Is it only that the user has cycled through the list elements and that no reset() has been issued?
Summary: How does the Iterator know to become invalid when the Collection is altered?
Summary: Can an iterator "reset()" throw an exception such as IteratorPositionInvalid if it is wrapping a db cursor which has no facility for reset?
Summary: Where are the destroy methods on the Iterator or on the Collection?
Summary: Can an interator have a next_n()? Or is this supposed to be via subtyping the interface?
Summary: Is it correct to offer the vanilla collection methods and add a new set for keyed access?
Summary: Clarifications on interfaces which support QueryableCollection.
Summary: When using iterator operations like adding, inserting, etc., how are changes reflected back to the datastores?
Summary: Appendix D states that a challenge structure consists of the MD5 of the arguments, but does not specify how the arguments are laid into a stream of octets for the MD5 algorithm.
Summary: Is it not possible that objects in a collection could have changed in between calls to the iterator accessing them?
Summary: Several of the bullets in section 11.1.5 are unclear.
Summary: How does this operation work?
Summary: Section 11.4.2 para. 3 says that FieldValues may be NULL. What if my datastore is a flat file without a concept of NULL. Does NULL take on the value of empty string for flat files?
Summary: Is there a way that I can delegate the functionality of the Iterators to the RDBMS itself?
Summary: Need all operations on the Collection be made using the SQL-92/QOL-93? If so, how is it possible to handle flat file datastores?
Summary: Need the OQS have any interface with the POS? I don"t see how the two can be interfaced.
Summary: It is not believed that the spec ever defines what a "malformed" PropertyName is. The closest definition is in para on page 26, section 5.1.1.2 and is not much help
Summary: Issue regarding implementation of the Query IDL specifications on a Java ORB. Issue involves implementing following idl definition from the CosQueryCollection module
Summary: Existing software based on messages with ASNI format description and a future version based on IDL. Does anybody know something about such a compiler?
Rather than classifying 'something' an aspect should classify a set or group of things - at a higher metalevel than 'quality' in BFO, for example. This impacts the Classifiers ontology. An instance of a classifier might specialize quality in BFO.
In order to get a type system which is CORBA independent we propose to change the exception which can be thrown by the union from CORBA::BAD_PARAM to std::invalid_argument. The impact for users is minimal as they can except std exceptions from the other std types they already use through this language mapping.
The component-formal-21-02-04 for CORBA 3.4 part 3 will be moved to its own separate specification.
IDL4 extends the IDL type system with int8/uint8/map/bitset/bitfield/bitmask, these all could be useful at the CORBA layer so to have guaranteed interoperability CORBA should define the CDR marshaling support for these new types
Summary: The enum should be named CORBA_CompletionStatus instead of CORBA_ExceptionType
Summary: Enum CORBATCKind omits the boolean kind (p.4-123, section 4.1.12) I recommend adding it to the end of list to preserve backward compatibility. Also missing tk_char.
Summary: 2) Attribute "name" in interface ValueMemberDef clashes with attribute "name"
inherited from Contained. A different name should be used, something like
"value_member_name"
Summary: Clarify the hash code algorithm
Summary: It is not clear whether the #pragma prefix is still part
of the repository Id. I think it should be.
Summary: Why is the 64 bit hash code at the end of the string and
not at the beginning ? This can speed up the comparison
when two repository Ids are different.
Summary: 2) How does one find out a RepositoryID for registering a factory or a streaming
policy?
Summary: Section 5.6.3 Hashing Algorithm (and 5.6.2)
long long hash = sha[1] << 32 + sha[0]
Summary: Clarify the exact semantics of computing the hash code and comparison semantics for type equivlanece. (lost email, paraphrase of issue)
Summary: I have an important issue concerning the C++ mapping and the fact
that application developers need to define/implement the concrete
value class.
Summary: In the Java mapping example on page 6-64 the operations are mapped to
public operations of the Java class. However in the C++ mapping example on page
7-95, the operations are mapped to protected pure virtual functions of the
generated C++ class.
Summary: What is the rationale for making ValueBase a value and not a native type?
It seems strange to me that a ValueBase "value" maps to java.io.serializable
in Java. Isn"t that what native was invented for?
Summary: A typo: on page 8-107, interface Account should inherit ":" from Describable and
value Currency should support Describable.
Summary: 1) Can the "public" modifier be applied to value operations? What is the default?
Summary: There are no typecodes for abstract interfaces. Does this mean
that abstract interfaces cannot be members of structs, unions,
or values? If so, I think this is a problem and we should add
typecodes for abstract interfaces.
Summary: Section number: 4.2.1
Problem: How can we bound the range of invoke ids in the IDL? Q773 requires
invoke ids in the range -128 to 127. ROS has no limits.
Summary: Section number: 4.2.1
Problem: Why is AssociationId a string? Should one explore the possibility of
using a combination of values supplied by both the initator and responder.
Strings do not seem to be the most scalable solution.
Summary: Section number: 4.2.1
Problem: The current text for DialogFlowCtr is for outgoing only. It should be
updated to reflect incoming messages from the legacy domain.
Summary: Section number: 4.2.2
Problem: There is a difference between the responder and initiator interfaces
because the initator cannot support the new association operations.
Summary: Section number: 4.3.1.2
Problem: Title and text should be changed to reflect that it is dealing with creating
an association rather than initiating a dialog.
Summary: Section number: 4.7.1
Problem: Is it necessary to indicate that RelativeRoundTripPolicy is not
propogated to the server? Also does TC interworking require the support of the
priority policies?
Summary: Section number: 5.2 and other sub-sections
Problem: The encapsulation BerData could potentially hold ASN.1 encoded via
other rules like PER. So is this name misleading, or too restrictive?
Proposed solution: One choice is EncodedData.
Summary: Section number: 5.4.1
Problem: DialogPortion should be a union rather than a struct. The complete IDL
is correct.
Summary: Section number: 7.1, page 108
Problem: Shouldn’t it be typedef string CORBA::ScopedName?
Summary: Section number: Fig. 27
Problem: Shouldn’t GwTcPduHandler be replaced by GwTcPduProvider?
Summary: Section number: 5.4.4
Problem: There is no way to send dialogue data in a continue confirm.
Summary: Section number: 5
Problem: There is no way to associate more than one instance of a TcPduUser
with a GT/AC pair for incoming SS7 messages.
Summary: OMG document orbos/98-07-03, section 4.7.4 under new_callback page 4-16,
the first paragraph reads
When the client side object adapter creates the object reference for the
callback object, it may invoke the
new_callback operation on the outermost inbound GIOP Proxy on the server
side and pass the callback object as the argument.
Say, there are no client-side firewalls and there is only one
server-side GIOPproxy firewall.
1. how does the object adapter or the client orb get access to the IOR
of the GIOPProxy object ???
2. how does the object adpater know that the object that is being
created/instantiated will be used as a callback
object ??
Does POA provide any m
Summary: Description:
The specification does not outline a specific method by
which to obtain the initial reference to the GIOPProxy object. We believe
that an interoperable solution for obtaining this initial reference is
needed in order to insure that all implementations will be able to be
correctly configured to contact all other implementations.
Summary: Proxified object references obtained by invoking
new_target() should not be passed between ORBs. Instead the original IOR
containing the target and firewall information should be passed. The reason
for this is that the IOR does not contain enough information to inform the
second ORB whether or not it is a reference for a NORMAL or PASSTHRU
connection, or whether it is a proxified reference at all. This issue is
very tightly related to issue 2, so we will describe how it fails for each
of the possible solutions to the PASSTHRU establishment problem outlined in
issue 2.
One solution for which this is not an issue is the solution
of using a port per target. However, this is not a viable solution because
it is restrictive and will fail under moderate load. For solution 1 we
don"t have a problem because no object reference is returned by
set_target(), therefore it cannot be passed to other ORBs. For solution 2
we have a problem because the second ORB won"t know whether it is supposed
to first invoke start_passthru() or simply start making requests. Therefore
it may get a connection type that it wasn"t expecting. For solution 3 we
have a problem because once the original connection has been made, the
reference is invalid. This occurs because the firewall does not have
knowledge of how many clients are expected to try to connect to that target,
and it may attempt to claim that port for reuse before another client has
connected.
Proposed Solution:
The passing of object references obtained by invoking
new_target() should be expressly prohibited by the specification. One
example is, "The object reference returned by new_target() may not be passed
to another client. Instead the original reference that was passed as the
argument to new_target() must be passed to the second client, and the second
client will follow the rules of the traversal algorithm to reach the desired
target."
Summary: Description:
Reusing PASSTHRU connections by the firewall should be
expressly disallowed by the specification. With the current wording of the
specification, a vendor may attempt to reuse PASSTHRU connections. While
this will work in some cases, it is not interoperable because there are
cases when reusing PASSTHRU connections will not work. For example,
connection reuse when SSL is in use will not work because all of the
information that distinguishes data streams is contained within the
encrypted portion of SSL packets. If two SSL connections try to share a
single connection, there will be an SSL protocol failure because the server
will not be able to separate the data streams before it processes the SSL
packet.
Summary: Description:
Clarification is needed on the passing of credentials.
Section 4.7.3 states that "Since all proxies will have access to the IOR of
the target object, and the certificate of the client, they can judge whether
this client may use a pass-through connection or not." Section 4.12 states
that "When a client establishes a normal connection to a target via a
trusted proxy and uses a secure transport (e.g. IIOP/SSL), in order to
achieve end-to-end authentication, the proxy will have to forward the
client"s certificate/identity to the server." Section 4.12 implies that the
ForwardedIdentity service context will only be used when using a secure
transport, but section 4.7.3 implies that the client certificate will always
be available. In fact, the ForwardedIdentity service context should only be
used in the case of a NORMAL connection using a secure transport because
those are the only conditions under which there is a notion of trust between
a requestor and the recipient of that request. This means that the only
mechanism upon which to base a decision of whether or not to allow a
PASSTHRU connection is the source host address/port.
Summary: Issues 7-9 refer to problems with routing and/or traversal of firewalls.
These problems arise due to a lack of required information about firewall
topology in the IOR. Most of these problems could be eliminated if it were
required that the servers place the entire chain of server-side firewalls
that must be traversed into the IOR. Specifically, the first paragraph in
section 4.8 should be modified so that the entire chain of firewalls is
always required, or those situations in which it should be required should
be stated. Some of those situations are outlined in the following issues.
Specifically, it is incorrect to state that "strictly it is only necessary
to convey information on the outermost inbound firewall."
The idl is
struct TcLinkedContext
{ DialogFlowCtr ctr; InvokeId ivk_id; InvokeId lnk_id; AssociationId a_id; };
While it is correct that these are both of the same type, the name of the type
could be confusing.
There is an assumption in the design that there is a one to one
association between a TcPduUser and a TcPduProvider
during a TC Session. This is enforced in the IDL through the
call
TcPduProvider::get_dialog_id()
and the factory call
TcPduProvider create_tc_pdu_provider(
in TcPduUser user,
out DialogId d_id)
raises(NoMoreDialogs);
Since the TcPduUser reference (or some sort of reference)
is not passed over in get_dialog_id(), the only conclusion
is that the reference has to be the one passed over in the
create, and therefore that each TcPduProvider is tied to
one and only one TcPduUser.
The Specification Translation from ASN to IDL does not appear to
require that each OPERATION carries a NoMoreAssociations exception.
This is necessary if the use of DialogFlowCtr can implicitly create a new
association during a call on an object that supports multiple associations.
As the interfaces currently stand, there is a minimum of 5 CORBA calls
per transaction
1. either TcPduProvider::get_dialog_id
or TcPduProviderFactory::create_tc_pdu_provider
2. TcPduProvider::invoke_req
3. TcPduProvider::begin_req
4. TcPduUser::end_ind
5. TcPduUser::result_l_ind
Given that a CORBA call is about 1 millisecond on average,
this makes for a highly inefficient interface from a high-performance
perspective,
and renders the distribution of these interfaces undesirable, and the
use of the TcPduProvider/User interfaces unlikely in a real system.
Ideally this should be reduced to a minimum of 2 CORBA calls, one for a call
going out, and one for the reply.
As far as I can see when using the 1988 TCAP version the submission
does not seems to handle the case where the subsystem number (SSN) is
used to seperate between several TC-User protcols per GT (typically
protocols from different vendors). The naming tree proposed for the
1988 TCAP protocol can only store one TC-User protocol per GT, that is
only one DefAc per GT can be stored (see section 4.3.1.1 in the
proposal).
The use of the SSN number for this purpose is explained in chapter
4.2.3 in the second paragraph in the ITU Recommendation Q.775.
It should be easy to fix this as one only have to use the same naming
tree structure proposed for the 1993 TCAP version in these cases.
Issue on Document orbos/2000-08-04, CSIv2 Joint Submission
Document: orbos/2000-08-04, CSIv2 Joint Submission
Subject: Identity Assertion of X.501 Distinguished Name is not good enough
Severity: Critical
Summary:
The Identity Token union contains a branch that is labled
X501DistinguishedName. A single DN is insufficient to identify an entity.
A path of X501Distinguished Names is needed instead. Also, other concerns
about naming types are raised.
Discussion:
An X.501 Distinguished Name is insufficient to identify a single entity.
The name must be accompanied by the name of its defining authority. In the
case of public key certificates, the names certificate authority must be
included.
The chain of DNs in this manner must be included up to a root authority
to have any definitive meaning.
This approach will be consistent with the client sending a X.509
Certificate Chain. A DN path is actually defined by the certificate chain.
Furthermore, the DN path should only come from an authority that is
acceptable to the server, whether it be a DN path, or an X.509
Certificate Chain.
The IOR should list the acceptable authorities and their name types.
It is becoming more an more evident that we must invent GSS_NT_Export_Name
types for X.509 Certificate Chain and X.501 DN path.
The SAS_ContextSec structure should list, instead of the naming types,
the naming authorities!
We shall assume that the name types of the asserted identities shall be
the same as the name types of listed naming authorities in the IOR.
This is the only way this procedure can work Interoperable and without
the client Guessing what it should do.
Suggestions:
An OID for an X.509 Public Key Certificate Chain shall be defined for a
GSS Export Name, and its encoding will be a ASN1 sequence of and X.509
certificate with the least significant certificate first.
An OID for an X.501 Distinguished Name Path shall be defined for a GSS
Exported Name, and its encoding shall be an ASN1 sequence of an X.501
Distinguished Name with the least significant name first.
To avoid having the target put a whole certificate chain in its IOR,
a new OID shall be allocated in which its GSS Exported Name encoding is a
X.501 DN path, but stipulates that the client should send a certificate
chain from that named authority. This GSS Exported Name shall only be
used in IORs and not for transmission in the Identity Token.
typedef Security::GSS_NT_ExportedName NamingAuthority;
struct CompoundSecMech
{ Security::AssociationOptions target_requires; IOP::TaggedComponent transport_mech; sequence<ServiceConfiguration> privilege_authorities; sequence<NamingAuthority> naming_authorities; };
Summary: There is a bit of confusion in the specification concerning the
exceptions that are possible during the internalization process.
The internalize operation can raise CosLifeCycle::NoFactory and
StreamDataFormatError exceptions. This operation calls the
internalize_from_stream operation of the Streamable interface that can
raise the CosLifeCycle::NoFactory, StreamDataFormatError, and
ObjectCreationError exceptions.The last paragraph on page 8-20 (August
1997 release) states that the ObjectCreationError and
StreamDataFormatError exceptions of the internalize_from_stream
operation originate from the read_object amd read_<type> operations on
the StreamIO interface. However, the ObjectCreationError is not raised
by any of these, according to the IDL in figure 8-6.
Summary: There is inconsistency regarding which model ConcurrencyControl needs to support
Summary: Problem: It is not necessary to have uniqueness of Invoke Ids within a dialog.
The invoke id can be reused as soon as it is no longer active.
Proposed solution: Put in text following the discussion of management of invoke
ids in the TC spec.
Summary: Section 4.7.4 - description of new_target operation.
The first para states:
"The new_target operation informs the firewall that it should prepare itself
to
receive requests destined for the specified target. The object returned
from this
operation is the destination on the firewall to which a request on the
target should be
sent i.e. the object_key in the return object should be used in the GIOP
request header."
and the last para says:
"The object returned by the new_target operation must contain an object key
which
allows the proxy to uniquely identify the target. A client is not required
to open a new
connection to the proxy server, even when the target object(s) are located
in different
servers."
The last sentence implies that the IOR returned from the new_target has the
same host/port number as the GIOPProxy. This may not be true. For example if
a firewall is load balancing across ports and network interfaces, the
host/ports may be differnt, and in this situation a new connection is
required.
Summary: Problem: Use UML to express relationship of interfaces.
I develop CosConcurrencyControl service for JacORB, but I don't
understud from specification how client can destroy LockSet.
When I create Object which allow concurrency access, I create LockSet.
When I destroy this Object I must destroy LockSet, because it's garbage,
bu no way for this does not exists.
As solution of this problem, I add in CosConcurrencyControl.idl next
changes:
exception LockExists{};
and method
void destroy raises (LockExists);
in interface LockSet.
As I undestand this changes is wrong, but have you idea about desigion
this problem.
Summary: Circular refrences to CosStream and CosCompoundExternalization,
i have not been able to find an idl compiler that can compile
these modules.
as aside, i have foud many syntax errors in the IDL you provide
as CORBAServices98-03-02.idl, in many of its interfaces, there are
typos, and it is not correct with the specifications.
Summary: In lock duration of Section 7.1 there are two descriptions. The role of the clients is vague to me
Summary: in section 4.9.2 last paragraph:
"Such a ProxyPushSupplier is guaranteed only to invoke operations defined in
interface I. Any event on the channel that does not correspond to an
operation defined in interface I is NOT passed on to the consumer. Such a
ProxyPushSupplier is therefore an event filter based on type".
My question is: if we have this proxy to block generic calls (push() in this
case) why does TypedPushConsumer inherit CosEventComm::PushConsumer, whish does
support push() ? Why should the generic calls like push() be blocked anyway
if (according to 4.7.1) TypedPushConsumer should support both typed and generic
models ?
Is there something I am misunderstanding ?
Summary: When multiple union labels resolve to the same union member, the property accessor for that union member has an additional (optional) argument
Summary: The following methods should be added to DIForeignComplexType, IID should be changed: string type_name(); string scoped_name(); string_repository_id(); more details in corresponding archive file
Summary: Third bullet should read:"...are sorted based upon interface name.." Last bullet should read "..the operations introduced in the current interface are mapped last and ordered.."
Summary: Example of "on both machines" does nor correspond to the diagrams. Add "on an intermediate machine" to sentence
Summary: There are a bunch of code samples that use a different font than the rest of the document
Summary: Section 4.1.18.6 Table 4-14: A few of these mappings don"t seem to make sense (i.e. the meaning of the different exceptions in each object system is much different
Using the static invocation interfaces, it is possible to receive a
valuetype that derives from the one declared in an operation, as long
as a valuetype factory is known in the receiver (truncation is not the
issue here).
The same is not possible at the DII: When creating the request, the
caller must indicate what type it expects, by forming a named value.
Conceptually, the typecode in the named value should be the typecode
of the base of all acceptable value types. However, if the ORB
receives a derived type, it has no means of unmarshalling it - even if
the application has knowledge about the derived type.
What is missing is an interface to make typecodes of value types known
to the ORB; with those, the ORB could then understand the CDR of the
valuetype, and create a DynAny when asked to.
The CORBA 2.3.1 specification does not cover the interaction between the
DynValue interface and custom valuetypes.
I frankly don't see any way that the DynValue interface can possibly
correctly handle a custom valuetype when the ORB does not have a factory
for the type. It is theoretically possible for DynValue to properly
work with a known custom type, but the implementation strategy could not
be based on parsing the marshalled form of the valuetype.
So, there are two issues that need to be addressed:
1. Should DynValue handle custom valuetypes at all?
2. For the set of custom valuetypes that it cannot handle, what
exceptions should be raised by each operations?
Due to the way that custom values are marshaled it is
nearly impossible for a bridge (or other process) to
process/forward GIOP messages which contain custom
marshaled values (which the bridge has no compile/run-time
knowledge of).
The main issue is that the "alignment" of the
custom marshaled data is unknown, other than the
data will always start on a four byte boundry due
to the presence of chunking.
Should/could the value encoding format be changed to
enforce eight byte alignment for all custom marshaled
data (chunks)? This would allow bridges and other
tools to process->[store]->forward messages containing
custom values.
The draft CORBA 2.3 spec (ptc/99-03-07) does not deal with a potential deadlock situation. If an object is explicitly deactivated with POA::deactivate_object(), the object remains in the active object map until all operations pending on the object have completed. Any attempts to reactivate the object (implicitly via a ServantActivator, or explicitly via activate_object_with_id()) must block until the pending invocations have completed. However, if a servant's implementation of an object deactivates the object and then (directly or indirectly through a call to another collocated object) reactivates the object, the invocation will deadlock.
Summary: I understand the params to be name value pairs of columns and the values for the
selection, update, delete, insert criteria
what is in the query? I would think if this is the whole query why would you
need the params??
I am a little confused as to the scope of the BiDirPolicy in the 2.4.1
specification. Is the BiDirPolicy a POA policy, an ORB policy, or both? In
section 15.8 paragraph 5 on page 15-55, the specification states:
"If the client ORB policy permits bi-directional use
of a connection, a Request message should contain an IOP::ServiceContext
structure in its Request header, which indicates that this GIOP connection
is bi-directional."
but then in section 15.9 paragraph 4 on page 15-59, the specification
states:
"In the absence of a BidirectionalPolicy being passed in the
PortableServer::POA::create_POA operation, a POA will assume a policy value
of
NORMAL."
but then again in the next sentence the specification states:
"A client and a server ORB must each have a BidirectionalPolicy with a value
of
BOTH for bi-directional communication to take place."
Could someone clarify for me what the intent for the scope of the policy was
here, and what the rationale behind that decision was? We are currently
reviewing how to use/fix BiDirIIOP in our submission to the firewall RFP,
and I would like to understand the issues regarding the scope of the BiDir
policy.
The creation of a TcUser interface with multiple associations does not have
a standardised way for destruction.
Proposed solutions
1. Add a destroy() method to TcUser
2. Explicitly state in the RFP that the CosLifeCycle::destroy() method should
be called once the object is no longer required.
Summary: The description of firewall traversal in orbos/98-07-03 4.11 has some
significant unstated assumptions, and prescribes an algorithm that has
several flaws.
In orbos/98-07-03 4.11 it says: "A client will determine if it needs
to go through a firewall to make a request on the target object. If
the client is in the same domain a direct invocation can be made. The
client can determine this be examining the host address information in
the target IOR." This assumes that the enclave structure maps to host
addresses in some way known to all clients. This needs to be made more
explicit.
Summary: In orbos/98-07-03 4.9 it says "However, it is desirable to provide a
portable means by which the object implementor can decide whether an
object could be accessible through a firewall. The following POA
policy is defined for this purpose:" but this policy can at most
control what components are included in references created by the
POA. Since the references do not have any mechanism to defend against
forgery, exclusion of a FirewallMechanism component does not prevent
access through a firewall. If an attacker obtains some other reference
with the FirewallMechanism component(s), it can convert a reference
created under NO_EXPORT into the reference that would have been
created under EXPORT.
The description of the policy needs to be changed to make it clear
that the policy does not imply any access control enforcement. The
ability of an attacker to forge references, either by combining parts
of other references, or otherwise, should be explicitly stated as a
security issue that must be addressed by means outside this
specification.
Summary: In ptc/98-10-11 5.8.1 it says "If a client has not set up any mechanism for
traditional-style callbacks using a listening socket, then the port entry
in its IOR must be set to the outgoing connection"s local port (as
retrieved using the getsockname() sockets API call)". At IOR creation time
there may be no connection, or there may be many, so the mandated local
port may be non-existent or ambiguous.
This topic was discussed on the firewall-rtf list during Feb-Mar 1999 but
was not raised as an issue.
Summary: The remark about masquerade at the end of ptc/98-10-11 15.8 is not
explicit enough. This is an important security issue and it needs to
be made explicit that a malicious client may claim that its connection
is Bi-Directional for use with any host and port it chooses, in particular
it may specifiy the host and port of security sensitive objects.
In general, a server that has accepted an incoming connection has no
way to discover the identity or verify the integrity of the client
that initiated the connection.
Summary: In ptc/98-10-11 15.8 from the end of the fourth paragraph "any
requests from the server on an objects exported by the client to the
server via this connection will be sent back to the client on this
same connection." to the eleventh paragraph "If the client initiates a
new connection it is not foreseen here that the server can use that
connection for requests on the object exported previously." it seems
to be implied that a reference must be passed via a connection if that
connection is to be used to invoke the referenced object with
Bi-Directional GIOP.
Summary: The submission makes no mention of HTTP tunnelling. There are many
firewalls which filter HTTP, FTP and email related traffic. Is the
omission based on the assumption that such firewalls will comprise
a CORBA conformant GIOP proxy on a well-known IIOP port? The Bi-
directional GIOP specification suggests not (section 5-1,
paragraph 2).
Is tunnelling regarded as an implementation matter? If so there
will be important issues such as relaxing GIOP/HTTP mapping and
security which the specification should clarify.
Summary: The issue comes from the following configuration:
Client - Tcp Firewall - Giop Proxy Server - Server
The server"s IOR will contains a FirewallComponent, which includes two
FirewallMechanisms - a TcpFirewallMechanism and a GIOPProxy. The issue
comes when the GIOP Proxy has multiple profiles, which may have different
host/port, and the TcpFirewallMechanism can only have one host/port. Does
that mean for any host/port specified in one of the GIOP Proxy "s profiles,
you always to connect to the host/port specified in the
TcpFirewallMechanism? This seems unrealistic since the Tcp firewall usually
provide a one-to-one mapping.
Summary: The Minimum CORBA submission describes exactly what should
be present in minimum CORBA (basically CORBA 2.2 including
the POA) in IDL/PIDL.
However, the Java language mapping in CORBA 2.2
does not include the POA -> just the APIs for registering
transient objects.
One cannot even take recourse to CORBA 2.3 to get the
language mapping, since much stuff (OBV, Java to IDL etc.)
was added in the intervening time. There does not seem to be
any existing document which documents a Java language mapping
of CORBA 2.2 including POA without lots of other stuff.
Summary: 5. The ValueHelper interface contains the method get_safe_base_ids, which is
inconsistent with current OBV terminology.
Summary: The OBV spec orbos/98-01-18 introduces a new repository ID
mechanism. It says in 5.6.2.1
>> We don"t recommand the classic id format "IDL:" <scoped name> ":"
>> <major> "." <minor> because it is not "foolproof" enough. (It is of
>> course allowable to use this format, since the CORE specification
>> does not mandate any particular form.)
The last sentence is not entirely correct, as 8.6.4 of formal/98-02-33
specifies
>> A definition is globally identified by an OMG IDL - format
>> RepositoryId if no ID pragma is encountered for it.
The issue is whether the OBV specification changes this default for
values or not
Summary: The OBV design for the "CORBA::tk_value" TypeCode defines a
potentially recursive constructed type that involves ValueMembers.
The "tk_value" TypeCode defines the entire complexity of the types
within the Value.
It is our understanding that when the ORB code that handles "Anys" for
C++ detects a tk_value TypeCode and needs to encode/decode the associated
Value object – (e.g., for Any::replace(TypeCode, void *) – it will
need to invoke a method on that object that understands the object
instance data and the associated state information. Further
examination of the TypeCode complexity will not be necessary by the
Any implementation, since this code would not have knowledge of or
ability to set the state information within the Value object itself.
The reason why the layout of the state information within a value
cannot be known by external code is that virtual inheritance of
abstract values and/or abstract interfaces makes it impossible to
calculate the offsets of the data members in a compiler
independent manner.
Summary: Using the IDL defined in Issue # 1352, we have the send() method, in interface Foo, which takes a Base value type as its formal parameter. Now suppose we wish to pass a Derived value type. When marshaling the list of repository ids, the marshaling engine has no notion of the formal type of the parameter, thus it does not know how many safe repository ids it needs to marshal.
There is a gap in the quantities and units ontology whereby we cannot represent counts of things, which do not necessarily have units, nor can we properly represent ratio values, which may involve scalar quantity values that do not have units. There is also a challenge in representing ratio values more generally, since there is no numeric value representing the ratio on the class.
Some message fields of type Boolean are listed as optional. This has a pretty ambiguous meaning for a boolean, which if present, is always True or False.
For one non-exhaustive example, some messages include a FINAL-MESSAGE boolean field that is optional. What does it mean when not present? It could be inferred that it is equivalent to False, but it could also be inferred that this is ignored when there is only one message, which would be the same as True.
We need to go through all these usages individually and decide if these should be required, rather than optional.
In C2MS 1.0, there is no indicator whether a tracking field (special fields in the Message Header and Heartbeat Messages) is required, optional or dependent. As such, in C2MS 1.1, we are marking these all optional, except for Heartbeat.SUBSCRIPTION.n.SUBJECT.PATTERN, which is being marked as dependent (required if NUM-OF-SUBSCRIPTIONS is > 0).
These should all be evaluated for R/O/D. One special case is HEARTBEAT.NUM-OF-SUBSCRIPTIONS. Normally, this should be required, because of C2MS11-135. However, in discussion for C2MS11-187, we went back to optional for this field. The rationale for this is that because it is a tracking field and therefore reserved for use by the PSM, rather than the generator of the message, it is difficult to understand what it means for a tracking field to be required. This reflects a shortcoming of the current C2MS documentation where it's not very clear what it means for a field to be a tracking field.
Finally, there are some tracking fields that should be considered for removal, such as CONNECTION-ID, MW-INFO, and USER from the Message Header. These fields seem useful for debugging, but not operations.
With the context stated above, the following need to be addressed in a future revision of C2MS:
The Resource Message stated objective is to enable publishing "computer performance data" via a defined C2MS message. However, using C2MS messages to monitor CPU load, memory utilization, and network port status seems wholly out of scope for satellite command and control. This provides what is essentially a rudimentary mechanism for resource monitoring, which could easily be better accomplished through industry standard mechanisms completely outside of C2MS.
In C2MS11-2, we removed CPU and memory related data from the Heartbeat Message. It makes sense to completely remove the Resource Message (via deprecation) for the same reason.
Each message includes a "[message name] Header table that repeats header field definitions as already listed in Table 8-3 Message Header Additional Information. Instead, this individual message table is intended to show what special values are applied to certain fields of the header. This needs to be made more clear, without duplicating information in the already-existing Header table. In other words, these tables should provide unique-to-the-message values rather than repeating header definitions.
A specific example of why this is not practical is that the existing set of tables all show the HEADER-VERSION 2019. Because the HEADER-VERSION is being updated in 1.1, each of these 31 tables must also be updated. In order to avoid this kind of issue in the future, these tables need to be reduced to just the necessary message-specific values.
See for example, "Table 8-108 Mnemonic Value Data Message Header". This table does not need to include the "Notes" column, since that is simply repeating word-for-word what exists elsewhere, and should not include the HEADER-VERSION row, since that is defined elsewhere, including its value.
To make this better, change the column name of column one to "Header Field Name". Additionally, should change the table title to "Table 8-108 Mnemonic Value Data Message Header Values".
Some XSDs were provided by NASA when v1.0 was created. However, these are only useful in a PSM for XML and should not be considered normative for the PIM. We don't have any intention to maintain/update these, so they should be removed. If NASA wants to create and deliver these to users, that is fine, but the OMG should not be the broker for these files.
See the listing of "Normative Documents" here: https://www.omg.org/spec/C2MS/1.0
The specification lacks a description how to map the @external annotation
The IDL to C++11 spec lacks a mapping for the min/max/range annotations
In C2MS2.0, we need to revisit the Req/Resp/Pub MEP, as is the same with MVAL Req, followed by an MVAL Resp, followed by an indefinite number and duration of MVAL Data Messages.
This should really be either a standard Pub-Sub construct or should just be a simple req/response.
This is one for C2MS 2.0. Capturing it here, because this is the only avenue to enter issues at present.
Instead of a F32 for version number, which then uses a year, like 2024.0, we should change this to a formatted string that uses Semantic Versioning, with a string that looks like the following:
MAJOR.MINOR.PATCH
Examples: "2.0.0", "2.1.1"
Note that this means changing the base type and the meaning of the current version numbers.
Note, too, that this shouldn't simply be type STRING, but should be something like VERSION-STR with the format defined by C2MS.
Also, consider getting rid of the separate header version and message content version. This is just something to bring up to the group.
This is for 1.2, but have to enter it in 1.1 as that is the only current jira project. I expect it to be deferred, but think it should be done in 1.2.
There is frequently confusion about how C2MS should be used. Normal use patterns are not described in the C2MS document, and this would be useful to add as a guide to users. This is especially true when C2MS is used in an enterprise environment, because common interpretation is critical.
The idea is to communicate context for how C2MS has been created and how it is expected to be used.
This could be in the form of a section called "System Architecture", "Guidance", "User Guide", or something like that.
The text for MVAL and related messages doesn't explain or give examples of how to specify for example an array or record – for example a BATV[1] or something more complicated like: SBUS.STATUS.PFRAME[27].STACK_DEPTH.
Any text addressing this should also discuss the XTCE repeat concept which the author of this issue believes today is handled by NUM-OF-SAMPLES.
The spec says "In case the union has an implicit default member it is initialized to that case", but it doesn't specify what is an implicit default member, maybe add "i.e., if the union does not have a default case and not all permissive discriminator values are listed"
Summary: Chapter 5 - Bi-directional GIOP misled me in a number of points, even after
numerous readings and a discussion with an author. I believe the chapter
contains all the pertinent information; it just has to be a bit more
carefully presented.
Summary: The firewall spec defines a number of tag values from OMG managed spaces.
The values of these tags need to be assigned.
Summary: The OBV spec introduces the concept of initializers, which maps
cleanly only to languages that support overloaded constructors.
Other languages, such as C, would typically offer functions to provide
inialization of values. Since initializers are not named, an intuitive
mapping is hard to find.
Summary: The definition for interface CodeBase in module SendingContext
has a method
CORBA::InterfaceRepository get_ir();
There is no type CORBA::InterfaceRepository. I believe this was
intended to say
CORBA::Repository get_ir();
Summary: There are no rules governing how to free value factories in C++.
Specifically, the ORB does not know what to do with the value factory at
shutdown, and applications do not know what to do with the factory
returned by register_value_factory. Directly deleting the factories may
be hazardous (e.g. if they are shared across multiple valuetypes or even
multiple ORBs), and leaving them around may introduce memory leaks.
Summary: Section 5.9.7 of orbos/98-01-18 says that the TypeCode parameters for both
tk_value and tk_value_box start with a string which is the type"s
repository ID. Why? For everything except tk_interface, the repository ID
is not visible as a parameter. I believe these parameter lists should not
include repository IDs to make them consistent with the others.
I assume that the
{member_name, TypeCode} pairs in the tk_value parameter
list should appear in the order of declaration of the members in the
valuetype. This is not stated anywhere.
The visibility of each member should be added to the tk_value parameter
list. Each entry in the list should contain
where the short refers to the Visibility of the member.
The parameter list for tk_value should probably have an additional
parameter which is the TypeCode of the concrete valuetype base, if any.
Summary: For boxed values that are structs, unions, or other constructed types with
member accessor and modifier functions, their member functions such as
value(), boxed_in(), boxed_inout(), etc. may potentially clash with the
names of those accessor and modifier functions.
Solution: make the names of such special member functions start with an
underscore, e.g., _value(), _boxed_in().
Summary: The custom marshalling streams CDRInputStream and CDROutputStream
don"t support the IDL fixed type. I propose adding the following
type definition and methods:
typedef sequence<fixed> FixedSeq;
abstract value CDROutputStream
{ ... void write_fixed (in fixed value); void write_fixed_array (in FixedSeq seq, in unsigned long offset, in unsigned long length); };
abstract value CDRInputStream
{ ... fixed read_fixed (); void read_fixed_array (inout FixedSeq seq, in unsigned long offset, in unsigned long length); };
Summary: The OBV spec is not very clear about whether the Java class
generated for an IDL value has a default (no-argument) constructor.
A no-argument constructor is needed so that the Helper class
can construct a value when demarshalling. However, it should be
package-private in order to limit its visbility to the Helper
class and not expose it to client code. This is also true for
state fields declared as private in the IDL value type (which the
spec currently states are mapped to private in Java).
Summary: There"s a problem with the mapping to Java for boxed IDL values
for non-primitive Java types, for example, a boxed string or a
boxed sequence. The currently specified write_Value call doesn"t
allow these to be marshalled correctly.
Summary: The spec does not contain a clear definition of how TypeCodes for
values and value boxes are constructed. There is something about
this in section 5.6.3, but this seems to describe a variant of the
algorithm rather than the algorithm itself. Section 5.9.7 needs to
be expanded to describe this in at least as much detail as the
description of the encoding of recursive sequence TypeCodes in the
current CORBA spec.
Summary: It is not clear from the spec whether or not value boxes can be
forward declared, and used recursively. For example,
value v;
struct s
;
value v s;
If value boxes are indeed syntactic sugar, the answer should be yes.
That brings the next question: Does this mean that one can call
create_box_value_tc(), supplying NULL for the original_type, and
then later on fill in the member typecode via fill_in_recursive_tc,
supplying a ValueMemberSeq of length 1?
Summary: Section 5.8.6 gives the BNF for the GIOP encoding of values but does not
describe the semantics behind them. Some of the semantics are referred
to in earlier section and intuitive for an outsider with a little CORBA
experience. Some of the the explicit semantics seem to be missing
altogether (e.g. the "" in <end_tag>). It would be useful if the
descriptions explicitly used the names within the BNF grammar or
explicit specifications for each name in the grammar was given.
Summary: One of the common patterns used in IDL specifications is to pass a
sequence of a data type in order to cut down on network round trips.
The current OBV spec (orbos/98-01-01) even suggests sending a graph of
objects and optimizing for the case where the same object occurs
multiple times in the graph (which I assume will normally be a small
number of the total objects). The spec seems to be inefficient for
sending a large number of small objects though. I have looked at the
errata before and don"t recall any relavent changes but know the RTF are
considering some now.
Summary: The OBV spec allows a value to support multiple interfaces. In C++, such
values
are specified to derive from the POA skeletons generated from those
interfaces.
This presents a potentially intractable problem: skeletons are not designed to
be inherited together with skeletons for other interfaces because servants do
not support multiple interfaces. (The Multiple Interface RFP isn"t finished
yet, right?) The top of page 20-104 of the latest C++ mapping (orbos/98-05-08)
explicitly says
Summary: 2) In addition to the ValueMemberSeq, the input parameters to
fill_in_recursive_sequence_tc include the target TypeCode
pointer, and the RepositoryId.
What is to be done with the RepositoryId parameter ?
Is the method supposed to update the Id as well ?
If that is the case, is it an optional/required parameter ?
Summary: 1) The fill_in_recursive_sequence_tc method is intended to act
upon an existing "tk_value" TypeCode. The signature indicates
that it should return a TypeCode pointer.
What TypeCode is supposed to be returned ?
If the signature is in error, the specification should
be corrected – if not, the specification requires
some additional explanation as to which TypeCode
needs to be returned.
Summary: The OBV spec defines CDROutputStream and CDRInputStream types values for
custom marshaling. The names of these types should not contain "CDR" since
there is nothing that prevents them from being implemented to use a data
representation other than CDR.
Summary: The OBV spec adds the notion of "chunking" because it claims that "it is
anticipated that value types may be rather large, particularly when a graph
is being transmitted. Hence the encoding supports the breaking up of the
serialization into an arbitrary number of "chunks" in order to facilitate
incremental processing." (orbos/98-01-18, page 5-55)
This "feature" should be removed from the spec, since it is the job of the
underlying transport to handle this issue. GIOP already provides
fragmentation, allowing transports to handle large parameters efficiently
– why should we build yet another fragmentation solution on top of it?
Summary: Can the "public" modifier be applied to value operations? What is the default?
In the Java mapping example on page 6-64 the operations are mapped to
public operations of the Java class. However in the C++ mapping example on page
7-95, the operations are mapped to protected pure virtual functions of the generated
C++ class.
Summary: The "in", "out", and "inout" modifiers on value operation parameters are
effectively comments. This is the case as a value maps to a language
pointer or reference. When it is passed in a local interface
there is no way to guarantee "in" or "out" semantics; it is passed by
reference which essentially has "inout" semantics.
These semantics should be explicitly stated.
Summary: A typo: on page 8-107 of the OBV spec., interface Account should inherit ":" from
Describable and value Currency should support Describable.
Summary: p 5-24, first paragraph of 5.3.1.3:
The implementation of operations may be remote if the value also
supports CORBA.Object.
typo p 5-30, last line of 5.3.2.6: may BE defined
Summary: Given:
abstract interface A {};
interface B : A {};
value C : supports B {};
Can an instance of C be passed by value to an operation that expects an A?
Summary: Semantic of register_value_factory is not clear
What do applications should expect if a factory is already
registered for a given repositoryId?
The operation returns the previous factory. But it is not
clear whether it is overriden or not.
Summary: According to the object-by-value C++ mapping, the value type that is
not boxed results in an abstract C++ class. Basically, the reference
counting methods are not provided (abstract). It is the responsibility of
application developer to define/implement a concrete class. Althought
this can be done, there are some issues:
Summary: The default ref-counting classes are said to be "fully concrete".
Is this really necessary?
What is the semantic of "_copy_value" for the ref-counting class?
=> suggest that "_copy_value" MUST NOT be implemented
(It is implemented by "_copy_value" of the real value type)
Summary: - What is the return type of "_add_ref" and "_remove_ref"
(defaults to "int", but what is the semantic of the result value)
=> propose to change to "void"
Summary: TypeCodes:
Summary: Missing member_kind and member_tc
Summary: Also, the OBV spec defines a describe_value() operation in interface ValueDef
which returns a FullValueDescription structure. Is there supposed to be another
operation which returns the shorter ValueDescription structure?
Summary: If a value type can inherit from a Boxed Value then what is the implicit name of
the Value Box"s single data member?
Summary: p.6.68: It is a bit awkward that boxed values of "complex" types map
all to the same type (i.e., as for typedefs, the value"s name appears
only in holder/helper classes), and that each boxed value of "basic" type
maps to its individual class. Instead, boxed values of basic types
could map to the corresponding java.lang.* class, e.g.
java.lang.Integer, java.lang.Short, etc. An issue with this approach
is that java.lang.Short and java.lang.Byte are not defined in JDK
1.0.2. I doubt however this JDK is still much in use; for its users,
short and octet could optionally map to e.g. CORBA.ShortValue and
CORBA.ByteValue (inspired from CORBA::StringValue).
Summary: 5.3.3: Is it possible to have a value inherit from (ie, support) a
boxed value ? If yes, the Java mapping of boxed values of type
string, sequence and arrays should be changed because String
and arrays can"t be extended in Java.
Summary: Can a Value type inherit from a Value Box type (the Value Box is described
as been syntactic sugar for a Value type)?
Summary: 1) ValueDefSeq is used in a couple of places but is never defined. A typedef
for it is missing.
Summary: ODL which shows an extra, optional parameter for exception information on property-get or property-set method is erroneous, since MKTYPLIB doesn"t allow extra parameter on property accessor
The GIOP specification does not say anything at all about the rules for marshalling ValueBoxes.
I believe the expected format is to marshal ValueBoxes as if they were a normal Value with a single member, and that they follow the normal rules about indirections and chunking. The spec should clearly state this.
21.3.9.2 states:
"In the DSI model, since the parameters are first available when the user code calls arguments, receive_request is called from within arguments. It is possible that arguments is not called in the DSI model. The target may call set_exception before calling arguments. The ORB shall guarantee that receive_request is called once, either through arguments or through set_exception."
The problem here, is that the DSI servant has already been invoked at this point, and the DSI implementation will be unaware that the server interceptor may have cancelled the invocation via raising a system exception or ForwardRequest user exception. So the DSI implementation will carry on, creating all sorts of wonderful havoc as it continues to interact with the ServerRequest PO.
Any vendors want to comment on what their PI implementation does now?
Proposed fix:
First, we should define a new system exception minor code that the servant implementation can detect so that it can clean up and get out of the way as expeditiously as possible when raised by arguments or set_exception. Perhaps a minor code for OBJ_ADAPTER? Should there be two minor codes, to distinguish a system exception from ForwardRequest as the reason for cancelling the invocation?
Second, we need some more text either in chapter 8 or 21 that states that any calls by the DSI implementation to ServerRequest::set_result or ServerRequest::set_exception will be ignored (or perhaps reraise the exception defined in the previous paragraph) if ServerRequestInterceptor::receive_request raises an exception.
There is a small issue with the restriction of where a valuetype chunk can end. The spec says
"The data may be split into multiple chunks at arbitrary points except within primitive CDR types, arrays of primitive types, strings, and wstrings, or between the tag and offset of indirections. It is never necessary to end a chunk within one of these types as the length of these types is known before starting to marshal them so they can be added to the length of the currently open chunk."
However, in the case of array of wchar, the length is not known before starting to marshal, since each char (in GIOP 1.2 and 1.3) is marshalled as a (sort-of) sequence of octets. I think it should be legal to end a valuetype chunk in the middle of an array of char.
The default annotation is not just for struct members, also for exception/union members but it can also be applied to a type, so also for example attributes of an interface/component/connector can have a default, all code generation related to that should also use the default whenever one is needed (for example starter code generation)
It is impossible to use the routing protocol to communicate with servers
that only support GIOP 1.0 or 1.1, because the information contained in
struct MessageBody does not contain enough information to determine the
alignment requirements of the contents of body member. The GIOP 1.0 &
1.1 RequestHeader struct contain an octet sequence for principle as the
last member, and specify no alignment requirements for the message
body. Thus, it is impossible for the final router to determine the
proper alignment for the message body when marshalling a GIOP Request
message for delivery to the target object.
The same problem applies to the Response message.
The spec doesn't make it clear what is a valid mix of policies and what
is invalid. For example, should it be legal to set a
RequestPriorityPolicy, MaxHopsPolicy or QueueOrderingPolicy value if the
RoutingPolicy is ROUTE_NONE?
Also, should setting both RequestEndTimePolicy and
RelativeRequestTimeoutPolicy be illegal? Or must the client/server pick
which ever one expires first?
I just noticed that the description of DynValue is totally silent on the
issue of derived valuetypes.
Here's an example to set things up:
// IDL
valuetype A
{ public short s; };
valuetype B
{ public long l; };
struct S
{ A an_a; };
// C++
DynamicAny::DynFactory df = ...;
B *b = ...;
S my_s;
CORBA::Any my_any;
s.an_a = b;
my_any <<= s;
DynamicAny::DynAny_var da = df->create_dyn_any(my_any);
DynamicAny::DynStruct_var ds = DynamicAny::DynStruct::_narrow(da);
ds->seek(0);
da = ds->current_component();
DynamicAny::DynValue_var dv = DynamicAny::DynValue::_narrow(da);
CORBA::TypeCode_var tc = dv->type();
cout << tc->id() << endl;
-----------
Now some questions:
1. What is printed by the above C++ code? "IDL:A:1.0" or "IDL:B:1.0"?
2. If the typecode is for valuetype A, what happens to the members
defined in valuetype B? Seems they must be inaccessable yet still
recoverable if I convert the DynValue back to an any and extract the
value, because I can't truncate a B to an A.
3. If the typecode is for valuetype B, we now have the interesting case
where:
tc->equivalent(ds->type()->member_type(0))
is false. Is this going to confuse programmers or programs? I think it
will, since it means that if I try to insert dv into another DynStruct
via assign() or the like, it will fail, since the TypeCodes are no
longer equivalent.
4. Do the answers change if B is truncatable and the program can find
the TypeCode for B (perhaps via SendingContextRunTime)? How about if it
can't find the TypeCode?
Fifth bullet near the beginning of this section states:
Incarnations of a particular object may not overlap; that is, incarnate shall not be invoked with a particular ObjectId while, within the same POA, that ObjectId is in use as the ObjectId of an activated object or as the argument of a call to incarnate or etherealize that has not completed.
Unfortunately, I do not see anywhere where the exception to be thrown from activate_object_with_id() for this case is specified. According to this text, if incarnate() is executing for a particular ObjectId, any calls to activate_object_with_id() should be rejected by the POA. This came up in comp.object.corba, where someone posted a question as to why Orbix 2000 throws the ObjectAlreadyActive exception for this case.
[..] It is used to indicate the relative amount
of time for which a Request or its corresponding
Reply may be delivered. After this amount of
time, the Request is cancelled (if a response
has not yet been received from the target) or
the Reply is discarded (if the Request had
already been delivered and a Reply returned from
the target) [..]
---------------------------------------------------------
Question:
Does it mean that client ORB just gives up or
does it mean that client tries, in kind of best
effort semantics, to cancel request on server?
If this cancellation fails, how will client user
be informed about this? By a minor code in
thrown Timeout exception?
Is it possible to clarify this?
The spec appears silent as to whether valuetypes are allowed to support local interfaces. Table 3-10, for example, says nothing at all about local interfaces.
There's a couple ways to look at this. First, valuetypes are not CORBA objects. Servants for local interfaces are direct CORBA object instances, i.e., the "local" declaration on an interface effectively removes the distinction between a CORBA object and its servant. If a valuetype were used as a servant for a local object, then the valuetype would itself also be a CORBA object. By this analysis, valuetypes should not be allowed to support local interfaces.
Another way to look at it is that the valuetype should just inherit the local interface's operations and attributes without having any subtype/subclass relationship with the base local interface. This would be a rather pointless approach to take, is there would be no possibility of using the valuetype polymorphically with respect to the base local interface.
The current mandatory annotation definitions (7.4.15.4.1) will cause problems when IDL specifications are attempted to be reused between profiles applying different requirements concerning annotations (for example a profile with annotations and a profile without annotations or two or more profiles with different sets of annotations).
As the IDL 4 specification has removed the support for the commented form of annotations there is no possibility anymore to declare annotations in a form that has semantic meaning in one profile and does not cause parsing errors in another profile not supporting (these) annotations.
Even with the commented form supported the mandatory specification of annotation definitions for applied annotations would cause similar kind of problems as it is likely that the definitions for the standard set of annotations from one profile would not be available in another profile not supporting those annotations.
Personally I do not see any use for annotation definitions (and in fact I cannot find any commentaries regarding that in the spec) but I would suggest that at the very least IDL compilers should be allowed to ignore any annotations not known to the profile for which the IDL compiler is configured.
Ideally I would like to see a specification without any mandatory annotation definitions leaving it up to the tool supplier to enforce annotation definitions or implement implicit (embedded) definitions.
Page 2-7 of the CosExternalization Service Specification (April 2000)
defines the following interfaces:
CosStream::Node
CosStream::Role
CosStream::Relationship
A CosStream::Node inherits from the CosStream::Streamable interface and
therefore is a streamable object – it has an external_form_id attribute
that enables a FactoryFinder to recreate the object using the
create_uninitialized operation.
Unfortunately, the CosStream::Role and CosStream::Relationship interfaces do
not support the CosStream::Streamable interface and therefore are not
"streamable;" in particular, there is no standard method to obtain a KEY for
them when it is time to internalize them.
Perhaps, I am missing something (it wouldn't be the first time 
, but
having them support the Streamable interface would certainly make
implementation much easier. Might I suggest the following:
interface Role: CosGraphs::Role, CosStream::Streamable
{ ... }at a minimum this would permit the CosStream::Node internalize_node()
operation and the CosStream::StreamIO read_graph() operation to use a KEY
value in the FactoryFinder to instantiate the object, before it is
internalized.
Section 23.14 of the CORBA/IIOP 2.4.1 specification lists the
complete IDL for a minimumCORBA implementation. However, the text in
the chapter and the IDL are inconsistent, for example, section 23.4.2
reads:
------------------------------------------------------------------------
---------------
The is_a operation is omitted so as not to introduce a requirement
either for holding
detailed type information in the object reference or for getting type
information over
the wire. Instead, minimumCORBA relies on design time resolution of type
checking
issues.
The non_existent operation is omitted, because of the design philosophy
of making
more decisions statically at design time.
The create_request operation is omitted, as the Dynamic Invocation
Interface is
omitted.
ptc/04-04-06 section 15.9.1 (top of page 15-67) states:
When the server receives a BI_DIR_GIOP_OFFER context it must send back a
BI_DIR_GIOP_ACCEPT context in both the strong and weak identification cases.
What happens if an ACCEPT service context is not returned? Either immediately
or ever?
Can a connection initiator, having sent an OFFER SC, send any further GIOP
messages over that connection prior to receiving the ACCEPT SC?
Should a connection initiator, having sent an OFFER SC but not having received
an ACCEPT SC, accept a Request (i.e in the reverse direction) on that connection?
a) for an object whose POA's BiDirId has been offered and accepted?
b) for an object whose POA's BiDirId has been offered but a corresponding
ACCEPT has not yet been received?
c) for an object whose POA's BiDirId has been offered and accepted only over a
different connection (to that over which the Request arrives)?
d) for an object whose POA has a BiDirId but it hasn't yet been offered?
e) for any object (e.g. one whose POA doesn't have a BiDirId)?
If an OFFER SC is sent on a Request message, can the corresponding ACCEPT
SC be carried on any GIOP message from the connection acceptor?
a) the associated Response
b) a Response not associated with the Request
c) a NegotiateSession message
d) a Request message for an object whose POA's BiDirId has already been
negotiated
If an OFFER SC is sent on a NegotiateSession message, can the corresponding
ACCEPT SC come piggy-backed on any GIOP message (that can carry SCs) or
must it come over a NegotiateSession message?
If two POAs (with EXPORT policy) are created and their BiDirIds are sent separately
in OFFER SCs on separate messages over a given connection, is a subsequently
received ACCEPT SC deemed to relate to one or to both of the offered BiDirIds?
Since I assume that a connection is effectively promoted to BiDir once the first
ACCEPT SC (indicating no error) is received. What is the point of insisting that
the connection acceptor "must" send additional ACCEPT SC?
In fact, even wthout any ACCEPT(no error) SCs, the occurrence of a GIOP Request
message from the connection acceptor would imply that the connection acceptor
has accepted the BiDirId. It would seem that the ACCEPT(no error variant) SC is
completely superfluous.
Given the ambiguities in the protocol, it seems likely that an implementation may
find the real-world interactions to have broken its model of the protocol. What should
a GIOP protocol machine do in such a situation?
If the connection initiator deems that the OFFER-ACCEPT protocol has gone wrong
should it be required to close the connection?
As there is no correlation between OFFER SCs and ACCEPT SCs, on a given
connection, does an ACCEPT (indicating an error) imply that the connection is
in an indeterminate state and should be closed?
If a connection is to be closed due to an error in the OFFER-ACCEPT protocol do
the normal rules regarding outstanding invocations apply? Do they apply for both
directions?
This issue was mentioned by Dave Stringer. I now file it as an issue.
When a bi-directional connection is established between a connection initiator and a connection acceptor, the connection acceptor may have to consider this bi-directional connection is volatile, i.e., the connection acceptor may lose (and is not able to resume) its capability of making invocations on such a connection anytime. For example, the connection may be lost due to network problems or the client may close a connection due to an idle time-out. These situations are not a problem for uni-directional GIOP because the ORB who wants to make an invocation can always initiate a new connection when the old connection is not available.
This problem may be less serious when bi-directional communication occurs only during the period of an invocation from the connection initiator. In other words, if the connection is lost and results in the failure of bi-directional "callback", the connection initiator may retry, effectively resuming the bi-directional connection.
On the other hand, for the use case in which a connection initiator "registers" an object reference to the connection acceptor, there is no guarantee that "callbacks" from the connection acceptor to the connection initiator will eventually succeed, assuming the network is not always down.
If this issue is a limitation that cannot be solved easily, we should spell it out in the spec.
Part of this issue has been surfaced in the discussions over the mail list. I now file it as an issue.
The Bi-directional GIOP spec says, "An object reference with a BidirectionalOfferPolicy of DENY must not be invoked over a bi-directional
connection." Satisfying this policy requirement does not close some potential limitation and ambiguity when other policies or policy instances are around.
For example, at the connection initiator side, we may have two object references one of which has BidirectionalOfferPolicy of DENY and the other has BidirectionalOfferPolicy of ALLOW. If these two object references point to the same server, according to spec, we need two connections to the server: one is bi-directional and one is not. However, having a non-bi-directional connection doesn't mean much. For invocations on the object reference with the DENY policy, the server side can always callback using the other bi-directional connection.
There is an argument (by Brian Niebuhr) saying that it's not realistic to both trust and not trust the same server. However, in practice, it's not always possible to tell whether two object references point to the same server or not. Furthermore, the client may decide whether or not to trust the server of an object reference depending on reasons other than the information about the server. For example, the client may decide to use BidirectionalOfferPolicy of ALLOW or DENY according to the source of an object reference.
On the other hand, at the connection acceptor side, things become a little more interesting. For an object reference with BidirectionalAcceptPolicy of ALLOW and effective BidirectionalOfferPolicy of DENY (e.g., the default policy on that ORB), what shall be the proper behavior of the ORB? According to the BidirectionalAcceptPolicy, "the ORB may accept and use any connections that a client has offered as bi-directional." However, shall we let the BidirectionalOfferPolicy of DENY prohibits the use of such a bi-directional connection? Or shall we allow the use of such a bi-directional connection because it's in the "reverse" direction?
The Bidirectional GIOP spec does not specify how many BI_DIR_GIOP_OFFER service contexts are allowed in a NegotiateSession or Request.
If only one such service context is allowed, it shall be stated clearly. Besides, because each BI_DIR_GIOP_OFFER service context can contain only either strong or weak BiDirIds (but not both), if there are both strong and weak BiDirIds on the ORB, the ORB has to use at least two GIOP messages to send them all.
If we allow multiple BI_DIR_GIOP_OFFER service contexts in one message, we'll have a problem in matching BI_DIR_GIOP_ACCEPT service contexts to these offers because there is no sequencing on offers and accepts.
The connection_complete field of the FirewallPathRespContext is under specified.
The fourth paragraph (including IDL) from the end of Section 1.5.4, Firewall Service Context, says,
“Once the connection has been established, the last intelligent firewall in the FirewallPath sends a FIREWALL_PATH_RESP service context in another NegotiateSession message.”
However, the last paragraph of this section says that, when the connection is not completely established, a FIREWALL_PATH_RESP service context with the connection_complete field of false is sent.
Furthermore, when the connection_complete field is false, the spec does not explain what are the situations that may cause incomplete connection establishment and what the client shall do for “further processing”. Shall the FIREWALL_PATH_RESP service context also contains information indicating what the client shall do?
PROBLEM:
It is not defined what happens if a non-conformant implementation receives a BiDir offer.
RECOMMENDATION:
State that a non-conformant implementation need not do anything - it may simply ignore the offer.
PROBLEM:
The target (ORB, POA, object, thread) of the Export and Offer policies and the side of the connection involved is incompletely specified.
RECOMMENDATION:
Define the two sides of a connection as the connection 'Initiator' and connection 'Acceptor'. The usual terms of 'client' (Initiator) and 'server' (Acceptor) become confusing in a bi-directional situation. Given those terms for each side, specify that the Export and Offer policies are used on the Initiator side. Specify that the Export policy may be applied to the ORB, the POA and/or to the thread. Specify that the Offer policy can be applied to the Initiator ORB, to a reference in the Initiator for an object in the Acceptor, or to a thread in the Initiator ORB.
PROBLEM:
The BiDir GIOP Document discusses three stages of connection setup, but it is unclear when each stage begins and when it ends. It is also unclear what NegotiateSession or Firewall activity can take place in each stage and what the order of processing may be.
RECOMMENDATION:
Rewrite the relevant portions of the document to specify the following (excerpted without edit from Brian Niebuhr's discussion of NegotiateSession contexts and the stages of setup):
"...during connection setup, only firewall contexts can be in the negotiate session message, NOTHING ELSE. After the connection is setup, there is a period before the first request or locate request where we can do session setup items. I think that in that period, only Bidir contexts can be sent, NOTHING ELSE. The first request or locate request indicates the connection_established period. Again, during that period I think only the Bidir contexts should be legal. This makes things very simple. There are no conflicts between firewall and bidir, and nothing else can go in a negotiate session message."
The title of Section 1.7, End-to-End Secure Connection, is misleading. There is no end-to-end security in the firewall traversal spec. All security mechanisms described in this spec are essentially mechanisms between a client, firewalls, and a server, not end-to-end. Thus, it is susceptible to the man-in-the-middle attack.
I'm saying we should fix the problem, but the title of this section and the caption of Figure 1-4 is certainly misleading. Besids, if the firewall traversal scheme described in the spec is actually susceptible to the man-in-the-middle attack, we may want to consider stating it somewhere in the spec rather than making people have a wrong impression that it is secure
The new BiDir spec is not clean about what BiDirIds shall be send to what connections. Because the BidirectionalOfferPolicy is either ALLOW or DENY, the only way to make bi-directional GIOP possible is to send all BiDirIds on an ORB to every connection that is used by an object reference that has effective BidirectionalOfferPolicy ALLOW. Besides, when a new POA with BidirectionalExportPolicy ALLOW is created, the BiDirId of this new POA must be transmitted to the server side of every existing bi-directional connections (before or in the next request).
The above implication derived from the spec is very inefficient. Consider an ORB with n bi-directional connections and m BiDirIds. The communication overhead for sending these BiDirIds is (m * n), while, in the ideal case, the communication overhead for sending BiDirIds is (c * n) where c is the average number of BiDirIds needed on each bi-directional connection. This ideal case can be easily achieved by allowing the BidirectionalOfferPolicy to specify a list of POAs whose BiDirIds shall be transmitted.
Proposed resolution:
1. Extend the choices of the value field of the BidirectionalOfferPolicy:
ALLOW_ALL – same as ALLOW now, but the implication shall be explicitely stated in the spec
ALLOW_LISTED – a list of POAs being provided in the policy
DENY – same as it now
2. Add a field to the policy to allow a sequence of POAs being specified.
PROBLEM:
The BiDir GIOP document allows all of the contexts that can be found in a GIOP query or response message to be also allowed in a NegotiateSession message. However, the interplay among these contexts is undefined. An example is the use in NegotiateSession messages of both CodeSet negotiation and BiDir connection setup. What can be used in what order is not defined.
RECOMMENDATION:
Only bi-directional GIOP and firewall contexts may be used in a NegotiateSession message in this version of GIOP. The contexts are the following:
· BI_DIR_GIOP_OFFER
· BI_DIR_GIOP_CHALLENGE
· BI_DIR_GIOP_RESPONSE
· BI_DIR_GIOP_ACCEPT
· FIREWALL_PATH
· FIREWALL_PATH_RESP
Further contexts may be added to new versions of the BiDir GIOP spec as their interplay with the existing set and the order of their use is carefully analyzed and documented. This effectively limits the scope of the problem to the bidir protocol and use by the firewall. The order and stage of processing the above contexts is discussed in another Firewall issue.
PROBLEM:
The BiDir GIOP document specifies that all BiDirIds must be randomly generated. However, persistent POAs must use the same BiDirId across sessions since they are stored in the IOR.
RECOMMENDATION:
A new policy is created (BiDirIdGenerationPolicy) that contains two fields:
field 1, the ID generation method, will take the value 'RANDOM' or the value 'REPEATABLE'
field 2, the ID type, will take the value 'STRONG' or the value 'WEAK'
The random generation method is adequately documented. The repeatable method will always generate the same BiDirId for a given POA. This effectively makes the ID a constant, but without the concern for storage. It also results in the end-user not having to deal with BiDirIds - they are handled entirely by the infrastructure.
The values for the ID type indicate whether the type of BiDirId generated is strong or weak.
This policy is placed on the client ORB and/or the POA in question.
PROBLEM:
The BiDir GIOP document does not specify the connections over which a BI_DIR_GIOP_OFFER should be sent.
RECOMMENDATION:
A BI_DIR_GIOP_OFFER will be sent over all existing bi-directional connections. If there are none, then a new connection will be established and its bidirectionality initiated.
PROBLEM:
The actions that result from the failure of a BiDir challenge are unclear.
RECOMMENDATION:
The client has proven itself untrustworthy. A BI_DIR_GIOP_RESPONSE containing a STRONG_FAILED result is returned to the client and all bi-directional connections to the client are closed.
PROBLEM:
The BiDir GIOP document does not specify which BiDirIds and how many of them are sent in a BI_DIR_GIOP_OFFER.
RECOMMENDATION:
All unoffered BiDirIds are supplied in a BI_DIR_GIOP_OFFER.
I'll use the following example to explain the implications that I derive from my understanding about the spec. I hope that it makes sense to you. If I'm wrong, please let me know.
Suppose I set up a client that has some POAs with BI_DIR_EXPORT policy ALLOW. The client wants to invoke a server that accepts bi-directional GIOP. This invocation will cause callbacks to a few objects on the client using bi-directional GIOP. The server is not allowed to create new connections to the client.
In the code of my client application, I can simply use the following statement to invoke the target object. And I would expect that the target object will call back some of the objects on the client ORB during this invocation.
obj = ...; // target
obj.invoke_target(...);
In order for the above scenario to work, I derive the following implications from the spec.
1. This invocation requires the target to call back on some of the objects on the client ORB. Because the client ORB has no knowledge about what objects might be called back, the client ORB has to ensure that the BiDirIds on all of its POAs that have EXPORT policy ALLOW must be available at the server side.
This conclusion also implies that the client ORB may have to track what BiDirIds that have been sent (and accepted) over every connection that allows bi-directional GIOP in order to figure out what BiDirIds have not yet been sent, assuming that you don't want to send all BiDirIds in every request. Furthermore, when someone creates a new POA with the EXPORT policy ALLOW later on the client ORB, the next new invocation on each bi-directional connection will also have to transmit the BiDirId for this new POA to the server side.
2. When the server receives a GIOP Request with BI_DIR_GIOP_OFFER service context, the server cannot dispatch the request to the target object implementation until this connection becomes bi-directional. Why? If the server dispatches the request before this connection becomes bi-directional, this request may fail because the target is not able to call back objects on the client ORB. In the case of Strong BiDirIds, the server may even have to send CHALLENGE and wait for RESPONSE before the server can dispatch the request.
If we put both implications together in the case of Strong BiDirIds, when someone creates a new POA with EXPORT policy ALLOW on a client ORB, a longer delay will be expected in the next request on every bi-directional connection because the server has to verify the BiDirId of this new POA no matter whether this new BiDirId will be used for callbacks on that connection or not. To me this overhead is not acceptable if it is the only way to implement bi-directional GIOP according to the spec. I hope the spec can be written in a way that allows efficient implementation, though efficiency is not always a concern for everyone.
PROBLEM:
The second paragraph on page 15-60 of the revised GIOP chapter only allows a BiDirOfferContext to be sent to a server if the ORB-level policy permits it:
"If the client ORB policy permits bi-directional use of a connection, a Request or
NegotiateSession (see MARS/04-01-01) message can be sent to the server that
contains a BI_DIR_GIOP_OFFER IOP::ServiceContext structure in the header that
indicates that this GIOP connection is bi-directional. The BiDirOfferContext
indicates to the server that the objects with the supplied BiDirIds are available for
invocation over that connection. To determine whether an ORB may support bidirectional
GIOP, the BidirectionalOfferPolicy has been defined (see Section 15.9,
"Bi-directional GIOP policy," on page 65)."
This, however, contradicts the rest of the document, which allows the ORB-level policy to be overriden at the object level. ("A BidirectionalOfferPolicy can be applied to a client ORB, and it can be overridden
for specific object references received by the client ORB." - Section 15-9, page 15-66).
Additionally, the first sentence of the above paragraph is worded in such a way that it defines a connection as bidirectional before it has accepted as such by a server.
Finally, a spurious reference to the submission document is included in the first sentence ("see MARS/04-01-01").
RECOMMENDATION:
Rephrase the paragraph as follows:
If the effective BidirectionalOfferPolicy of an object in the client is set to ALLOW, a Request or NegotiateSession message that contains a BI_DIR_GIOP_OFFER IOP::ServiceContext structure in the header can be sent to the server, offering bi-directional use of the connection. The BiDirOfferContext indicates to the server that the objects with the supplied BiDirIds are available for invocation over that connection. To determine if bidirectional GIOP may be supported, the BidirectionalOfferPolicy has been defined (see Section 15.9, "Bi-directional GIOP policy," on page 65).
If a service context negotiation fails by way of the NegotiateSession
message in either direction. how does the sender (client or servers side)
get an indication back to the sender?
Does Codeset come before/with/after BiDir negotiation?
Can Codeset come before/with Firewall Traversal in Negotiate Session
meesages?
On a connection in which BiDir is negotiated, but no Codeset
is negotiated, will the reverse direction be able to negotiate
code set?
Does Codeset get negotiated in only the other direction?
If so, will that happen in Negotiate Session meesages orRequest Messages?
Does the CodeSet get negotiated in Negotiate Session?
If so, does Codeset continue to get negotiated in Requests?
The following paragraph raises an interesting issue. If we follow this to the letter
From the second paragraph on page 1-30 of the Firewall Final Adopted Spec (ptc/04-04-01):
This document supercedes the previously adopted CORBA firewall specification. In
addition, the changes to bi-directional GIOP, specified in Chapter 15, supercede the
adopted specification for bi-directional GIOP. These specifications are not backwards
compatible with the previous specifications and they are intended to make it possible
to create a functional protocol for the interoperation of ORBs and firewalls.
There seems to be a discrepancy in the changes proposed to CSIIOP and CSI modules. The draft document has identical changes to both. I think the intent of the Errata was to have only one, just switch them from CSIIOP to CSI. However, Brian's convience document doesn't show the change. Now, the draft document ptc/2004-01-01 that we are voting on has both. What to do? Should that be represented by another document, namely CSI, with it's changes, just like 2004-01-02 is? Cheers, -Polar
Yeah, I see the problem. Yet another consequence of the adopted spec changing existing spec without calling out the change in the section meant to identify changes to existing specs. So it looks like the fix involves: 1. Section 1.9.2 and 1.9.3 in ptc/04-01-01 [henceforth referred to as document A] should disappear. 2. The first half of section of document A starting from the second para of the section and upto and including the last but one paragraph on page 1-20, should be appended to Section 24.2.5 "Identity Token Format" of Chapter 24 of Core with the title (that is the CSIv2 Chapter)[henceforth referred to as document B]. Also append a row to table 24-2 with info about ITTCompundToken. 3. The IDL in section 1.9.3 of document A should be merged properly into the IDL for the CSI module that appears in section 24.9.2 document B. 4. The addition to CSIIOP IDL as it appears in Section 1.5.2 of document A should be merged appropriately into the IDL for CSIIOP in section 24.9.3 of document B. 5. In document B insert a section 24.5.1.6 "TAG_IIOP_SEC_TRANS" with a two liner explanation of what this tag is together with the IDL for it from section 1.5.2 of document A. I'd suggest that we file this as an issue and resolve it in the FTF roughly along the lines suggested above.
The BidirectionalPolicy insufficient for persistent objects.
The BidirectinoalExport Policy is a POA policy and it only has two values
of ALLOW and DENY. If it is ALLOW, then a TAG_BI_DIR_GIOP componenet
should be placed in the IOR. It is stated that the ORB must generate a
random identifier when the POA is created. However, that will not work for
persistent objects in which the BiDirectional Offer must remain constant.
Also, there is no default specified if this policy is not placed on a POA,
and no default for the RootPOA.
As I understood it, the Firewall Traversal specification was to use new
CSIv2 Compound Identity types to give the target server the complex
principal composed of the client and the authenticating firewall traversal
path. The server was to be authenticated to the client in much the same
way. This functionality appears to be missing in the specification. It is
easily fixed by returning a CSIv2 IdentityTokenSeq from a successful
firewall negotiation, specifying the backwards firewall authentication
trail from the server to the client.
The Negotiate Session message is unwieldy in that if it is used to send
service contexts, there are no general ways to govern its use other than
by special rules, all of which special cases are not accounted for in the
specification.
For example, when do you sent Bidirectional service contexts as ooposed to
firewall contexts? Can you send transaction contexts? Codesets? Codebase?
CSIv2? Can you send BiDir service contexts while firewall contexts are
being processed?
The NegotiateSession message is a single typed GIOP message that is sent
between both Client and Server to negotiation service contexts, and
further to initiate and negotiate bidirectional GIOP.
Having a single message is problematic in that a connection, once
negotiated bidirectional may have different requirements for such things
like Codesets, etc. Getting a NegotiateSession message after a
bidrectional set up, the endpoints will have difficulty discerning the
orientation of the NegotiateSession message.
At the very least NegotateSession messages should have an orientation,
much like the GIOP Request and Reply messages do.
I'm not so sure they must be correlated with a "request id", but different
message types would help. I would suggest two messages,
NegotiateSessionRequest and NegotiateSessionReply to maintain the
client-server orientation, respectively.
i have a few questions about the POA ThreadPolicy type
MAIN_THREAD_MODEL.
first, the 2.4.1 spec (00-11-03), sec 4.2.3.2 , 'perform_work' states,
"If called by the main thread, this operation performs an
implementation-defined unit of work; otherwise it does nothing."
how is a distinguished main thread supposed to be reliably determined?
i'm not sure we really need to define this. i'd think what we're trying
to say is that the thread that calls perform_work() is the thread that
will be used to do the work, and it is up to the application to make
sure this happens. in section 4.2.3.3, the spec states,
"For maximum portability an application should call either run or
perform_work on its main thread."
to me it seems the intent is to let the application determine what the
'main thread' is.
second, what happens if an application calls both run & perform_work?
and what happens if the application calls run from multiple threads? it
isn't really clear what the difference in request handling with regard
to the thread used is between run() & perform_work().
right now the spec seems to imply through the use of the message loop
example in section 4.2.3.2 that perform_work is really intended to be
used to handle situations where a single thread must be used for all
application activity. now add to that the note on pg 11-12 about using
the main thread model:
"Note - Not all environments have such a special requirement. If
not, while requests will be processessed sequentially, they may not all
be processed on the same thread."
my interpretation is that ORB::run would be used in cases where you
simply want the POAs to be accessed sequentially, but the application
doesn't care about which thread the implementation uses, but you would
need to call perform_work to specifically hand the application defined
main thread to process requests.
my suggestion (finally ;^) is that we should state perform_work should
be called, on whichever thread the application likes, if it wants to
hand a specific thread to the ORB to do work. otherwise, calling
ORB::run from any thread simply means the implementation is free to
handle requests for servants associated with main thread model POAs on
whatever thread the implementation may choose (including a new one), in
keeping
with the requirement that the requests be processed on each POA's
servants sequentially..
one more question: does it make sense to state that a callback type of
architecture won't work when using this threading model?
Problem:
Since CORBA/e is for embedded constrained systems, one should be using LW Services as a minimal compliant point this would still allow one to offer up a Full Services in its offering but the other way around would not be compliant.
Suggested Change
The suggested change is to use LW Services definitions for CORBA/e.
In chapter 11 'Unreliable Mulicast Inter-ORB Protocol' the struct PortableGroup::GroupInfo is discussed. However in the consolidated IDL and the IDL available from the OMG web site, this struct has been replaced by PortableGroup::TagGroupTaggedComponent. Which is correct?
All IDL/C++ that is used in the text should be have a different font like done in the other parts of the spec, that is for example int8_t/uint8_t/Base::Base/
There shouldn't be a semi colon after the namespace closure, this is done in more places in the spec, search for "namespace", closing should be "}" and not "};", see chapters 6.3/6.5/6.23.1/6.26.2/6.27.2/6.28/6.29
For the following places the declared destructors should be using override and not virtual as they override the base class destructor. This should happen to:
Review and fix all uses of DESTINATION-COMPONENT in the Miscellaneous Elements of subjects for all messages where that field is used. Also, see 2016 GMSEC ISD for discussion of destination component and add that back in to the description of Configuration Status Message. See pages 74 and 78.
This is needed for representation of tensor and vector quantities for the quantities and units ontology, and for representation of certain machine learning algorithms, among other requirements.
Both Firefox and Chrome give the following error when clicking on the link to the XMI format on page https://www.omg.org/spec/CSRM
XML Parsing Error: not well-formed
Location: https://www.omg.org/spec/CSRM/20210801/CSRSM-Profile-XMI.xmi
Line Number 116, Column 99:
CORBA 3.4 should have support for int8/uint8/map/bitset/bitfield/bitmask/bitvalue for DynamicAny, DynamicSkeleton, Interface Repo, Any/TypeCode and other CORBA APIs related to types
RE: CCM chapters document [orbrev] 99-10-04, section 61.6.2, page 61-45.
The document citation indicates that the integrity of the valuetype –
that is, the received marshalled state – is to be preserved in an
ORB-mediated operation, even if that valuetype cannot be unmarshalled,
either partially (truncated) or at all. If this value is then passed to
another operation, the original marshalled state is to be transmitted.
This preserves the transmitted object in its entirety, regardless of
local implementation concerns. This is obviously necessary for bridges
or event processing, such as through the notification service.
So the question arises, what happens if you have a partial (truncated)
unmarshall and the recipient application changes the local state of the
valuetype through its attributes or local operations? How can/will you
even know the state was changed? Do you ignore the changes and send the
originally received marshalled stream, send only the new valuetype even
though it is a truncation of the original, or "merge" the new values for
the unmarshalled part followed by the original appended data for the
truncated part? Should this third option be possible through an
explicit ORB call – that is, the application is responsible to identify
the change in state to the ORB? I assume that the semantics of
"truncatable" must come to include the understanding that data in the
truncatable portions may not be contextually dependent on the inherited
parent of the valuetype.
As a further question, is there a reason why this semantic
interpretation should not be extended to be a general requirement rather
than only with respect to transmission of anys? My experience has found
that passing anys tends to be expensive and is avoided where it can be.
A more general interpretation permits transmission of a comprehensive
data structure among intermediate agents that only use (unmarshall) the
information they need.
Suggested changes to the AssemblyFactory interface.
AssemblyFactory Issues.
1. Ease of use Issue. After the create operation is performed, one is
force to call lookup to get the Assembly that just got just created. Why is
a cookie returned by the create operation instead of an Assembly? Is the
reason because of security? If the interface were more open this would
still allow a secure implementation to be implemented.
Suggested change is to return an Assembly instead of a Cookie. Change
destroy operation to take in an Assembly parameter instead of Cookie.
Change lookup operation to take in a name parameter. These changes
make it consistent with the other CCM interfaces, such as Container,
KeyLessCCMHome, ComponentServer, and ServerActivator.
2. Multiple users Issue. For multiple users, how does a client know what
assemblies are created. Add a get_assemblies operation that returns a list
of assemblies. These changes make it consistent with other CCM interfaces,
such as Container, ComponentServer, and ServerActivator.
3. User-friendly identifier for Assembly Instance issue. Add an input
name parameter that can be assigned to the Assembly instance that gets
created. Add a read only name or label attribute to the Assembly interface.
in the BaseIDL there is a class StructDef which has the Attribute members of
Type Field. How can I model a IDL struct with more than one entry?
I think there should be a aggregation from StructDef (1<>----->*) to the Field
class (Page 8-10 of the CCM Spec).
*) With EnumDef there is the same problem, I guess a assotiation from EnumDef to
string (1<>----->*) would solve it (Page 8-10 of the CCM Spec).
*) Also with ExceptionDif and its attribute members (Page 8-11 of the CCM Spec).
module Components
{
valuetype Cookie
;
};
1. Naming style used in this definition violates rules defined in
"OMG IDL Style Guide" (ab/98-06-03).
2. Naming style used in this definition is inconsistent with other parts
of the CCM IDL, for example:
module Components
{
valuetype PortDescription
;
valuetype FacetDescription : PortDescription
;
}
In section 4.2.5 of the CCM spec formal/02-06-65, it is said that "Servant lifetime policies may be defined for each segment within a component", but there is no way to do it. Lifetime policy is declared in the CCD descriptor of the component, as an attribute of the "servant" XML element, and is implicitly applied on all the segments of the component(when it is segmented) !
Suggested resolution: to leave the servant element as it is, expressing a DEFAULT lifetime policy, and to add the same servant element as an optional child of the segment element. This will specify the lifetime policy of the segment and override the defautl one. DTD has to be changed as follows :
<!ELEMENT segment
( segmentmember+
, containermanagedpersistence?
, extension*
>
<!ATTLIST segment
name CDATA #REQUIRED
segmenttag CDATA #REQUIRED >
becomes:
<!ELEMENT segment
( segmentmember+
, servant?
, containermanagedpersistence?
, extension*
>
<!ATTLIST segment
name CDATA #REQUIRED
segmenttag CDATA #REQUIRED >
In OMG document formal/02-06-65, in section "1.3.3 Component Body", there
is this text:
"Declarations for facets, receptacles, event sources, event sinks,
and attributes all map onto operations on the component's equivalent
interface. These declarations and their meanings are described in
detail below."
In the following sections, I see facets, receptacles, event sources,
and event sinks described, but I see no mention of attributes.
It would be usefult to have an example of attributes in an appropriate
place, as outlined by section 1.3.3.
In section "1.10 Configuration with Attributes", I see that configurators
are described, but I see no example of using attributes directly
to configure a component.
It would be very useful to include a small example to illustrate
how to configure a component directly by using attributes.
Diego Sevilla Ruiz <dsevilla@ditec.um.es> gave this
C++ example on the CCM mailing list ( http://moriarty.dif.um.es/mailman/listinfo/ccm ):
======================================================
component Whatever
{ attribute long cacheMaxKb; };
home WhateverHome manages Whatever
{
};
// C++
WhateverHome_var weh = // obtain ref
Whatever_var we = weh->create();
we->cacheMaxKb(200);
we->configuration_complete();
======================================================
I don't suggest that this example be used verbatim,
but a similar example would be useful to have in the
CCM spec.
In section 1.1.2 of the CCM specification:
1.1.2 Ports
===========
..... The component model supports four basic kinds of ports:
Well, that list includes five things, not four.
So, is an attribute considered a port or not?
The wording in this section needs to be clarified in the CCM
specification, because it is not clear if an attribute
is a port or not.
Summary: On page 9, paragraph beginning with "Within an interface...." should read "..attributes should appear after operations..."
The following information is sent in order for the specification to
clearly state if components and local interfaces can support abstract
interfaces (the specification is confusing on this point).
CORBA 3.0.1 does not explicitely states if a component can support an
abstract interface, thus it can be considered that it is possible. If so
a big problem arises as local interfaces inheriting abstract ones is
confusing in the specification.
In addition, it is neither explicitely stated that provides and uses
declarations can or cannot be of types defined through abstract
interfaces. It does not seem to make sense for a port to be an abstract
type. Facets will never be used by value, and an operation cannot
(should not) return the reference of a facet or a valuetype (which would
be in favor of provides to be defined using abstract interfaces).
Consider the following definitions which are correct regarding
formal/02-12-06:
/* omg idl3 */
abstract interface I
{ void foo () ; } ;;
interface C : Components::CCMObject, I { } ;
local interface CCM_C : I { } ;
According to formal/02-12-06, the last line may not be correct. Local
interfaces may not inherit abstract interfaces (section 10.5.28). (I use
may as it is confusing and can lead to various understanding of the
spec.)
1. State in the CORBA 3.0.1 that components cannot support abstract
interfaces. In favor: Could ne considered as a minor change. Against: a
component reference cannot be returned by an operation that can return
an object by value or by reference. This solution looks cleaner that the
second one from a software engineering point of view.
2. Clearly state that components and local interfaces can support
abstract interfaces. This use may be surprising from a software
engineering point of view, but may be important for some users. This
bring back the debate "quality vs powerfulness".
In any case, I think it should be clearly stated if local interfaces may
or may not inherit abstract ones.
Identifier (FPI).
These FPIs are required for the CAD, CSD, CCD and CPF DTDs.
Proposed resolution:
Adds the CCM DTDs on the OMG web site and adds the following text in the specification:
The CORBA Software Descriptor must refer to the DTD using the following statement: <!DOCTYPE softpkg PUBLIC "-//OMG//DTD CORBA Software Descriptor 3.0//EN" "http://www.omg.org/dtd/softpkg_3_0.dtd" />
The CORBA Component Descriptor must refer to the DTD using the following statement: <!DOCTYPE corbacomponent PUBLIC "-//OMG//DTD CORBA Component Descriptor 3.0//EN" "http://www.omg.org/dtd/corbacomponent_3_0.dtd" />
replace
<!DOCTYPE corbacomponent SYSTEM "corbacomponen.tdtd">
with
<!DOCTYPE corbacomponent PUBLIC "-//OMG//DTD CORBA Component Descriptor 3.0//EN" "http://www.omg.org/dtd/corbacomponent_3_0.dtd" />
The Component Assembly Descriptor must refer to the DTD using the following statement: <!DOCTYPE componentassembly PUBLIC "-//OMG//DTD Component Assembly Descriptor 3.0//EN" "http://www.omg.org/dtd/componentassembly_3_0.dtd" />
replace
<!DOCTYPE componentassembly SYSTEM "componentassembly.dtd">
with
<!DOCTYPE componentassembly PUBLIC "-//OMG//DTD Component Assembly Descriptor 3.0//EN" "http://www.omg.org/dtd/componentassembly_3_0.dtd" />
The Component Property File must refer to the DTD using the following statement: <!DOCTYPE properties PUBLIC "-//OMG//DTD Component Property File 3.0//EN" "http://www.omg.org/dtd/properties_3_0.dtd" />
The description for Object::get_policy (in the Core, section 4.3.7.1)
states:
"The get_policy operation returns the policy object of the specified
type (see Policy Object on page 4-32), which applies to this object. It
returns the effective Policy for the object reference. The effective
Policy is the one that would be used if a request were made."
For a policy defined by PI, I don't see anyway for the ORB to implement
this operation correctly, since there isn't any way for it to know how
to properly resolve any client override policies with the policy
information stored in the IOR.
When a invocation is actually in process, the ClientRequestInterceptor
can use the information available in the ClientRequestInfo interface to
get the client override and the IOR policy data and do the correct
resolution before continuing with the request. However,
Object::get_policy() needs to do the same type of thing, but it has no
invocation context to do it in.
I think the same problem also applies to the implementation of
ClientRequestInfo::get_request_policy().
I think we need a new interception point to do this work. Something
like:
local interface PolicyInterceptor
{ any determine_effective_policy(in PolicyInfo pi); };
local interface PolicyInfo
{ readonly attribute Object target; readonly attribute Object effective_target; readonly attribute IOP::TaggedProfile effective_profile; IOR::TaggedComponent get_effective_component (in IOP::ComponentId id); IOP_N::TaggedComponentSeq get_effective_components (in IOP::ComponentId id); };
If this turns out to be an acceptable solution, then we should also
change ClientRequestInfo to:
local interface ClientRequestInfo : RequestInfo, PolicyInfo
{ ... };
and remove the redundant operations.
Issue: The association of entity component primary key and PSS key is unclear. There is only one attribute as the primary key in the CCM entity component, PSS has no primary key. An entity can be identified uniquely by the PSS key, but currently PSS permits several keys, and each PSS key can be composed of several attributes. Consequently, it is difficult to establish association between entity component primary key and PSS key, and the create and find methods can not to be mapped to the corresponding methods of PSS.
The CCMObject interface contains numerous operations for generic
connection management (in addition to the type-specific operations
defined by equivalent IDL for a component).
However, there's a separate set of "connect" and "disconnect"
operations for each kind of port, i.e., receptacles, emitters and
publishers. This is inconvenient for generic software that treats
ports generically, such as the deployment infrastructure in an
implementation of the Deployment and Configuration specification.
The set of operations might even get larger in the future, when
Streams for CCM becomes available.
I thus propose to add generic "connect_feature" and "disconnect_
feature" operations that is able to interconnect compatible ports
regardless of the type of port.
Proposed resolution:
In section 1.11.1, "CCMObject Interface," add the following two
operations to the CCMObject interface:
module Components {
interface CCMObject : Navigation, Receptacles, Events
;
};
Add the following explanation to the same section:
connect_feature
The connect_feature operation connects the object reference
specified by the connection parameter to the component feature
specified by the name parameter. The feature must be either a
receptacle, emitter or publisher port.
If the feature identified by the name parameter is a receptacle
port, the connect_feature operation acts equivalent to calling
the connect operation on the Receptacles interface.
If the feature identified by the name parameter is an emitter
port, the connect_feature operation acts equivalent to calling
the connect_consumer operation on the Events interface. A nil
"cookie" value is returned.
If the feature identified by the name parameter is a publisher
port, the connect_feature operation acts equivalent to calling
the subscribe operation on the Events interface.
If the feature identified by the name parameter is neither
receptacle, emitter or publisher port, or if the component does
not have any feature by that name, the InvalidName exception is
raised.
disconnect_feature
The disconnect_feature operation dissolves the connection
identified by the ck cookie to the component feature specified
by the name parameter.
If the feature identified by the name parameter is a receptacle
port, the disconnect_feature operation acts equivalent to calling
the disconnect operation on the Receptacles interface.
If the feature identified by the name parameter is an emitter
port, the disconnect_feature operation raises the InvalidConnection
exception if a non-nil cookie is passed as the ck parameter;
otherwise, it acts equivalent to calling the disconnect_consumer
operation on the Events interface.
If the feature identified by the name parameter is a publisher
port, the disconnect_feature operation acts equivalent to calling
the unsubscribe operation on the Events interface.
If the feature identified by the name parameter is neither
receptacle, emitter or publisher port, or if the component does
not have any feature by that name, the InvalidName exception is
raised.
Issue: It is good to let CCM component definition can have operations directly, but not indirectly by "supports" keyword. The "supports" adds too much complexity when defining a compoment and compiler implementation
I'd like to report an issue that exists in both the CORBA Component Model Specification (formal/06-04-01) and also the Lightweight CORBA Component Model specification (ptc/04-06-10) please.
In section "6.11 Component Inheritance" of formal/06-04-01 there is the statement : "A derived component type may not directly support an interface."
This same statement is made in "1.11 Component Inheritance" of ptc/04-06-10 and in "3.17.2.3 Component Inheritance" of the CORBA 3.0.3 spec (04-03-02).
But, in both "6.3.2.4 Inheritance and supported interfaces" of formal/06-04-01 and "1.3.2.4 Inheritance and supported interfaces" of ptc/04-06-10 there is the following:
"For a component declaration with the following form:
component <component_name> : <base_name>
supports <interface_name_1>, <interface_name_2>
;"
The above example is giving equivalent IDL for a declaration that the preceding statements regarding component inheritance say is not permitted. It should presumably be removed.
The CCMHome interface does not provide a mechanism for locating the container that created a home. The lack of a method to get a home's container is inconsistent with the rest of the CCM model. Furthermore, this method would be very useful as it would provide a means to navigate from a component to its ServerActivator, which is currently not possible.
Resolution:
Replace the following text in formal/02-06-05 on page 1-41
interface CCMHome
{ CORBA::IRObject get_component_def(); CORBA::IRObject get_home_def (); void remove_component ( in CCMObject comp) raises (RemoveFailure); };
with
interface CCMHome
{ CORBA::IRObject get_component_def(); CORBA::IRObject get_home_def (); void remove_component ( in CCMObject comp) raises (RemoveFailure); Container get_container(); };
and add the operation description
get_container
The get_container operation returns a reference to the Container object that created this CCMHome
Summary: Description:
There may be some network topologies where the traversal
algorithm is not sufficient for a firewall to find a server. This is due to
an unstated assumption that all addresses within the outermost inbound
firewall are addressable from the outermost inbound firewall. Consider for
example the following topology:
| -----*Firewall B*-----Network B Internet ----- |
| -----*Firewall C*-----Network C |
Service Network (DMZ)
Assume that the addresses on the service network are
globally routable addresses, Network B uses RFC 1597 addresses and Network C
uses RFC 1597 addresses. This topology could be possible, say for a
government agency that has sub-agencies that share some resources (service
network) but maintain separately administrated networks. In this case the
outermost inbound firewall for a server on Network B or C is Firewall A.
However, when new target is invoked on Firewall A, it won"t know from the
host address whether to open a connection to Firewall B or Firewall C.
Proposed Solution:
There are several possible solutions to this problem:
1) Explicitly state the assumption described in the
description section
2) Mandate that implementations allow for the
configuration of the next inbound firewalls
3) Mandate that servers on Network B or C in such
configurations use Firewall B or C as the outermost inbound firewall.
There may be other solutions to this problem. These were
the ones that immediately presented themselves.
Summary: It should be possible to have negative invoke ids.
Summary: Problem: make factory creation operations conform to the IDL style guide
Proposed solution: change the capitalization and put in underscores between
words
Summary: Problem: Title does not cover the use of SS7 as signaling transport. This case is
not a TC interworking.
Summary:
I would like to get some clarification on the PASSTHROUGH/Untrusted Proxy
issue.
In page 4-45, the spec says "It is possible to support pass-through through
multiple proxies. For example if in the above example there was another
proxy B2 between B and C, during processing the new_target operation from A,
B can try to establish a pass-through connection to C via a call to
new_target on B2. If this fails, due to NO_PERMISSION for example, B should
fall back to try to connect through B2 using the NORMAL mode.".
If the connection (B - B2) is NORMAL, the whole connection is not a
PASSTHROUGH since the client will see the B2"s identity in the SSL session.
Should B throw back the NO_PERMISSION to the client if B get NO_PERMISSION
from B2 for PASSTHROUGH connection? If the answer is no (seems to me that is
what spec says), does this mean that it is possible that the client request
a PASSTHROUGH connection but actually get a NORMAL connection?
Summary: 2. The current language mapping mixes both generated code with user
written code in the same source file. This poses a very complex "tool"
issue for IDL compilers which is unnecessarily complex.
Summary: On page 5-44, a new production has been added to the grammar to allow the use of ValueBase to be used as a base type. (<base_type_spec> ::= ... | <value_type_spec). My concern is that all other types of base type specifiers have a PrimitiveKind. However, either you guys forgot or didn"t want to have, that a value or ValueBase does not have a corresponding PrimitiveKind enum value. This becomes essential later on when we want to go into the InterfaceRepository, and find that some type is a ValueBase, we will need to know this. The easiest way to do this could be through a PrimitiveDef, where it"s def_kind attribute is a dk_Primitive, and to satisfy the IDLType interface for they type attribute, we could return a TCKind of tk_value or tk_ValueBase. An alternate could be to not go the PrimitiveDef route and use a different approach. Perhaps we could have a method in the Container or Repository interfaces called create_ValueBase. This would be much like creating an unnamed type such as a sequence, a string, primitive, or array (i.e. get_primitive(), create_string(), etc. in the Repository interface). This is less likely though because create_ValueBase would need to return a type. We could return a ValueDef, but create_ValueBase wouldn"t have enough information passed to it to create on and besides, a ValueDef is named. We could have a whole new definition interface called ValueBaseDef, but this way is a pain if you ask me.
Summary: 1. There are no write_Abstract and read_Abstract methods on
DataInputCtream and DataInputStream. This looks like an oversight
to me.
Summary: It has been pointed out to me that we have no way of narrowing
from abstract interfaces to non-abstract interfaces and value
classes. In Java, the helper"s narrow method has a signature of
org.omg.CORBA.Object, so it cannot take an abstract interface
type. In C++, the generated classes for abstract interfaces
have an _narrow method with the right signature (taking an
AbstractBase_ptr), but generated classes for values and regular
interfaces don"t have such a method. It seems like we would
need to add overloaded narrow methods in all these places to
make this work as envisaged in (for example) numbered paragraph
3 of section 8.3.
Summary: Section 5.3.1.2 says that non-public data members should be mapped
so that "the private part of the state is only accessible to the
implementation code and the marshaling routines."
Section 6.3.1 says that non-public data members are mapped to
private instance variables.
The problem is that the Java marshaling routines are in the Helper
class, which cannot see private instance variables in the value class.
The proposed solution is to modify the Java mapping to map the default
IDL state to the default (package visibility) Java state instead of
private.
Summary: In Section 5.9.1 on p. 5-55 of orbos/98-01-18, the spec says "the sending context is responsible for listing the repository ID"s for all the base types to which it is safe to truncate the real
type, going up (the derivation hierarchy) to, and including if appropriate the formal type". Currently, there is no portable way to obtain the list of type safe repository ID"s
from within the marshaling engine in order to be marshaled on-the-wire properly.
Summary: The Objects By Value (OBV) Specification (orbos/98-01-18) introduced
the concept of "keyword identifiers" in an effort to avoid breaking
existing IDL specifications. It specifies that a keyword identifier
is a word that is treated as a keyword only when used in a keyword
context, and is otherwise treated as a regular identifier.
4) Finally, the keyword identifier approach gives the impression that
IDL extensions can be made at no cost, which is simply not true.
Summary: The Objects By Value (OBV) Specification (orbos/98-01-18) introduced
the concept of "keyword identifiers" in an effort to avoid breaking
existing IDL specifications. It specifies that a keyword identifier
is a word that is treated as a keyword only when used in a keyword
context, and is otherwise treated as a regular identifier.
3) It allows IDL specifications that, while not unparseable, are
highly ambiguous, especially to a human reader. For example, Jeff
recently posted answers on how the following is to be parsed, but
there is no way that someone reading the OBV spec would be able to
figure out the rules he gave:
interface public
{ ... };;
value safe
; // Is this legal or an error?
value foo2 : safe safe
; // What about this?
value foo3
;
While all of these constructs can all be parsed using the appropriate
number of look-ahead tokens (by the way, the grammar is not LALR(1)
as the OBV Spec suggests), it is hard to read and even harder to
parse correctly. Many IDL compilers still fail to properly implement
the name lookup rules in the existing CORBA specification, and adding
keyword identifiers will only make that situation much worse.
Summary:
The Objects By Value (OBV) Specification (orbos/98-01-18) introduced
the concept of "keyword identifiers" in an effort to avoid breaking
existing IDL specifications.It allows IDL specifications that are simply unparseable. For example:
interface ValueBase {};
struct S
;
This is ambiguous because the compiler cannot know whether the type
of struct member "v" refers to the ValueBase interface or the
ValueBase keyword identifier.
Summary:
The Objects By Value (OBV) Specification (orbos/98-01-18) introduced
the concept of "keyword identifiers" in an effort to avoid breaking
existing IDL specifications.
1) First and foremost, the addition of keyword identifiers changes
the IDL grammar into a context-sensitive grammar, which are known to
be notoriously difficult to parse.
Summary: Reconcile RMI/IIOP upcall and helper class
Summary: p 5-50, 2nd paragraph of 5.6.2.1: it seems to me that in existing
ORBs, version inconsistencies between, eg, structs, may already corrupt
memory. The difference now is that preservation of values sharing
could make matters worse. It would be great to have this issue better
explained.
Summary: typo p 5-50, first paragraph of 5.6.2.1: *s*IDL compilerS keep on spitting...
Summary: Suggested changes (to section 5.4.1 of orbos/98-01-18) are:
1. Remove the ``;"" from the end of the definition of <value>. (It"s
in the modified <definition>.)
2. Remove [ <supports_token> <scoped_name>
{ ``,"" <scoped_name> }* ]
from the <value_inheritance_spec> non-terminal move it to a new
non-terminal, <value_supports_spec>.
3. Change the definitions of <value_abs_dcl> and <value_header>,
replacing [ <value_inheritance_spec> ] by [ <value_inheritance
_spec ] [ <value_supports_spec> ].
Summary: Section 5.4.2 "New lexical type - Keyword Identifier" the statement is made that
"new keyword identifiers should only be added such that the resulting grammar is
still easily parsable, e.g. is LALR(1).". It seems to me that is not true even for
the newly introduced keyword identifiers in many cases.
Summary: Above rules seem to imply that the
"safe" keyword identifier can only occur before the first scoped name in the
<value_parent_spec>, whereas I think the actual intent is that it can only
occur before a non-abstract value type, of which there is at most one in the
list, although it need not be the first. Since this can"t be expressed in the
rules exactly, I would simply amend the rule to be:
<value_parent_spec> ::= ":" [ <safe_token> ] <scoped_name>
{ "," [ <safe_token> ] <scoped_name> }
*
and simply express the semantic restriction in the text. There already is a
brief mention of the semantics of the "safe" keyword in section 5.3.2.5
"Substitutability Issues". Perhaps another sentence or two would help clarify
the intended usage.
Summary: The OBV spec (orbos/98-01-18) does not specify which TypeCode operations apply
to Value and ValueBox types. For example, are id(), name(), member_name(),
member_count(), member_type(), etc. valid for Value and ValueBox or should they
raise BadKind exception?
I don"t see why they should not be valid. Normative text should be added in
CORBA 2.2 section 8.7.1 TypeCode Interface to reflect this and the comments in
the IDL should also be updated.
Summary: 1) Can a Value type inherit from a Value Box type (the Value Box is
described as been syntactic sugar for a Value type)? If so, what is the
implicit name of the Value Box"s single data member?
Summary: Page 2-30, top of page, end of section 2.7.1: There is a label "Examples:" but no example follows
We would like to add a request to add the following IDL type. Just add a sequence of CCMHome typedef sequence<CCMHome> CCMHomes;
The D&C IDL part doesn't match 06-04-02. For example TargetManager is not correctly in 06-04-01 and has its errors in 06-04-02
The NVList has a count, which is defined as long, it would be better to make this an unsigned long. This has impact on ORB::create_list, change the type of argumetn count to unsigned long. Also update NVList::get_count to have an unsigned long argument.
In the Interceptor interface there is a destroy method which can throw a system exception just like all other corba calls. What is the behaviour when the orb shutdown is done and an Interceptor::destroy() call throws an exception? Should the ORB ignore this exception and continue the shutdown or should it return the exception to the caller. I would except ignore the exception and continue but the spec doesn't describe the behaviour.
The tags for unreliable multicast are missing. // The following are defined in 03-01-11 const ProfileId TAG_UIPMC = 3; const ComponentId TAG_GROUP = 39; const ComponentId TAG_GROUP_IIOP = 40;
The minor code for add_reply_service_context is not correct. The spec says: Indicates the behavior of this operation when a service context already exists with the given ID. If false, then BAD_INV_ORDER with a standard minor code of 11 is raised. If true, then the existing service context is replaced by the new one. The minor code should be 15.
This corba spec describes POAManagerFactory. I have been searching on the web and it seems for example Orbacus has the possibility to do a resolve_initial_references ("POAManager"). This seems not possible with the latest corba spec. This seems an usefull extension. The only option there is now is to get the RootPOA, get from there the POAManagerFactory and use that again.
For activate_object_with_id it is described that when SYSTEM_ID has been set and the object id was not generated by this system or tis POA we throw a BAD_PARAM, but the minor code is not described. Shouldn't this have an unique minor code?
The following methods are not described in this chapter: Object make_object (in string repository_id, in ObjectId id); IOP::TaggedProfileSeq make_profiles (in string repository_id, in ObjectId id); These are mentioned in 21.10.3
In the C++ example code of 22.11.3 Messaging::ExceptionHolder_ptr is used, for valuetypes there is no _ptr, the could should read Messaging::ExceptionHolder *
There are some issues with the definition of ExceptionHolder. In 22.16 it is as below, see the raise_exception_with_list, this seems to have two arguments here, in 22.7 there is just one argument. The same problem also appears in the draft 3.1 spec. Also, there is no CORBA::ExceptionList defined in the spec at all, there is Dynamic::ExceptionList but no CORBA::ExceptionList. valuetype ExceptionHolder { void raise_exception() raises (UserExceptionBase); void raise_exception_with_list( in CORBA::ExceptionList exc_list) in Dynamic::ExceptionList exc_list) raises (UserExceptionBase); private boolean is_system_exception; private boolean byte_order;
The CORBA spec describes the following about the wait_for_completion parameter of the POA::destroy call: The wait_for_completion parameter is handled as follows: If wait_for_completion is TRUE and the current thread is not in an invocation context dispatched from some POA belonging to the same ORB as this POA, the destroy operation returns only after all active requests have completed and all invocations of etherealize have completed. If wait_for_completion is TRUE and the current thread is in an invocation context dispatched from some POA belonging to the same ORB as this POA, the BAD_INV_ORDER system exception with standard minor code 3 is raised and POA destruction does not occur. We have a use case where we have an ORB with two POA's, A1 and B1, each POA again has a child A2 and B2. In case we get a request for a servant of A2 to destroy POA B2 and we specify TRUE for wait_for_completion then we get an exception back, but this doesn't seem locally. We understand that when we want to destroy A1 when handling a request using a servant of A2 that we get an exception at that moment. We propose the change the description as following: The wait_for_completion parameter is handled as follows: If wait_for_completion is TRUE and the current thread is not in an invocation context dispatched from some POA that is a child of this POA or from this POA itself, the destroy operation returns only after all active requests have completed and all invocations of etherealize have completed. If wait_for_completion is TRUE and the current thread is in an invocation context dispatched from some POA that is a child of this POA or from the POA itself, the BAD_INV_ORDER system exception with standard minor code 3 is raised and POA destruction does not occur.
In case get_slot is called from withing an ORB itializer chapter 21.4.3.1 says a BAD_INV_ORDER with minor code 10 is thrown, this should be 14 as mentioned also in 21.7.2.11
The draft document says the following in 21.9.1. The description about the type of exceptions sounds very vague. Shouldn't the spec be more detailed, which type of exceptions should be ignored specifically? Any exceptional return from the invocation of any operation of the ORBInitializer interface other than those resulting from the failure to instantiate a portable interceptor object shall result in the abandonment of the ORB initialization and destruction of the ORB. Any ORBInitializer implementation that needs the ORB to ignore any thrown exceptions can simply catch and discard them itself.
In the draft 3.1 spec chapter 21.7 says the following: An Interceptor's behaviour may itself be modified by one or more Interceptor Policies. These Policy objects are created using a call to ORB::create_policy and are associated with an Interceptor during registration (see Section 21.7.2, ORBInitInfo Interface). All Policy interfaces defined in this section are local. The ORB can be accesed via the implicit get_orb operation of ORBInitInfo. The ORBInitInfo is passed on the pre_init and post_init call of the ORBInitializer but what should be the orb in the pre_init call? The orb is not initialized at that moment? Shouldn't it say that calling get_orb on the ORBInitInfo in the pre_init call gives the default exception that is given when get_orb is called on a local object?
The spec describes that anonymous types are deprecated and will be removed in the future (as below), but this is used throughout the spec. Before deprecating this fully, update the spec to not used anonymous types: >From 3.11.6 IDL currently permits the use of anonymous types in a number of places. For example: struct Foo
{ long value; sequence<Foo> chain; // Legal (but deprecated) }Anonymous types cause a number of problems for language mappings and are therefore deprecated by this specification. Anonymous types will be removed in a future version, so new IDL should avoid use of anonymous types and use a typedef to name such types instead. Compilers need not issue a warning if a deprecated construct is encountered.
Struct ServiceInformation is wrong, the sequence<> lines should be removed. struct ServiceInformation
{ sequence <ServiceOption> service_options; ServiceOptionSeq service_options; sequence <ServiceDetail> service_details; ServiceDetailSeq service_details; };
The is an error in the ServiceDetail struct. service_detail is listed twice, the first one should be removed. struct ServiceDetail
{ ServiceDetailType service_detail_type; sequence <octet> service_detail; ServiceDetailData service_detail; };
Update: struct IOR
{ string type_id; sequence <TaggedProfile> profiles; }; to struct IOR
{ string type_id; TaggedProfileSeq profiles; }; And also use CORBA::OctectSeq instead of sequence<octet>
Minor formatting issue in: abstract valuetype Pollable
{ boolean is_ready( in unsigned long timeout ); PollableSet create_pollable_set( ); }; boolean is_ready is in the wrong font in the idl overview
This section defines struct PolicyValue
{ CORBA::PolicyType ptype; sequence<octet> pvalue; }; Which should be as below because anonymous types are deprecated struct PolicyValue
{ CORBA::PolicyType ptype; CORBA::OctetSeq pvalue; };
Third line of 23.1.3.4, ACTIVE must be bold
Proposal to change PortableInterceptor::AdapterState to a real enum. Now it is a short with constant values, but this means there is no real relationship between the type and the possible values as possible with an enum. With for example C++ we then can let the compiler check if we don't use incorrect values. module PortableInterceptor { enum AdapterState
{ HOLDING, ACTIVE, DISCARDING, INACTIVE, NON_EXISTENT }; };
Proposal to change PortableInterceptor::ReplyStatus to a real enum. Now it is a short with constant values, but this means there is no real relationship between the type and the possible values as possible with an enum. With for example C++ we then can let the compiler check if we don't use incorrect values. module PortableInterceptor { enum ReplyStatus
{ SUCCESSFUL, SYSTEM_EXCEPTION, USER_EXCEPTION, LOCATION_FORWARD, TRANSPORT_RETRY, UNKNOWN }; };
In 15.4.2 and 16.4.1 get_implementation is mentioned, but this method is nowhere else in the spec. Should this method be there? So far as I can see this is deprecated and should be removed.
Table 21-1 has the following note: When ClientRequestInfo is passed to send_request, there is an entry in the list for every argument, whether in, inout, or out. But only the in and inout arguments will be available. What is the behaviour when I request an out value? It says only that in/inout are available, but when I have an argument that is of out and I do get the value, do I then get an empty value (which could lead to a crash when using it), do I get an exception? That must be clearly specified by the spec
16.10 lists register_initial_reference. It would be usefull for dynamic systems to also have a unregister_initial_reference (in ObjectId id).
We see more and more use of unicode. It happens more and more that users have code that gets unicode (wchar) commandline arguments. In order to smoothen corba usage for these users we propose to add interface ORB
{ Object string_to_object ( in wstring str ); };
For a 24x7 system that doesn't shutdown and gets reconfigured it would be useful if we could for example change "-ORBDefaultInitRef" after the ORB has been initialized. That then would be used for any objects resolved after that. Maybe we could add CORBA::ORB::arg_list (inout arg_list argv); Which would change the arglist
ServiceContext is defined as: struct ServiceContext
{ ServiceId context_id; sequence <octet> context_data; }; Anonymous types are deprecated, this should be struct ServiceContext
{ ServiceId context_id; CORBA::OctetSeq context_data; };
This chapter defines register_orb_initializer. This itself is ok, but at the moment we have a 24*7 system and we get a new ORBInitializer shipped in for example a DLL we maybe want to get rid of a certain orbinitializer that we registered earlier. This is currently not possible, we propose to add an unregister_orb_initializer which makes it possible to unregister an orbinitializer again
The corba spec defines a lot of policies. In 4.8.5 client exposed policies are listed. We do have several of them, also policies could be applied at several levels, but some of them can't be applied to each level. To our idea the scope at which policies can be applied should not only be in the possible, but also part of the policy itself. That way application code and the corba orb could check this. Maybe add this to policy typedef unsigned long PolicyScope; const PolicyScope POLICY_SCOPE_OBJECT = 0x01; const PolicyScope POLICY_SCOPE_CURRENT = 0x02; const PolicyScope POLICY_SCOPE_SCOPE = 0x04; const PolicyScope POLICY_SCOPE_POA = 0x08; const PolicyScore POLICY_SCOPE_CLIENT_EXPOSED = 0x10; Then add to the interface Policy readonly attribute PolicyScope policy_scope; This attribute can then be set in the policy with the values above as bitmask. This can be documented clearly in the documentation, orbs can check this, etc.
The CORBA spec defines the following types to proposage messaging qos. This is really nothing more then propagating policies values. struct PolicyValue
{ CORBA::PolicyType ptype; sequence<octet> pvalue; }; typedef sequence<PolicyValue> PolicyValueSeq; This is now in the Messaging module, but the propagation of policy values is something that we want to use for ZIOP but also seems usable for other libraries. Instead of duplicating this struct to different modules I propose to move this to the IOP module.
For several cases it would be helpful to have a:
Policy create_policy(
in PolicyType type) raises(PolicyError);
The name of the method has to change, to not conflict with the existing method
The context has to be define as local interface instead of a regular interface
The ORB is intended to be a local object, it is not to be used outside of the process, so it should be a local interface
the specification already deprecated anonymous types, but to our idea it would be time to update the specification to say that anonymous types are illegal and remove all references to them
The overview of all system exceptions is missing several ones which seem to be availalble in http://www.omg.org/docs/omg/03-01-04 For example NO_IMPLEMENT_TABLE minor code 8 is missing
The spec describes respository_id which should be repository_id. Is on two places, in 4.3.14 and 4.3
The POA state inactive is not used consistent. On several places it is called deactivated instead of inactive. For example in 11.3.8.2, in the transient bullet, it mentions: "Once the POA's POAManager enters the dactivated state". Chapter 11.3.2.1 describes clearly the states are: active, inactive, holding and discarding. I would propose to scan the complete spec for these incorrect POA Manager state.
The argument of the set_servant call has a small typo, it must be p_servant to match the full IDL spec some pages further
I would propose to change in the POAManager the following: State get_state(); string get_id(); to readonly attribute State the_state; readonly attribute string the_id; The get method just hide the fact that this are readonly attributes
Add a typedef for the POAManager id and use this throughout the spec for POAManager, POAManagerFactory and IORInterceptor add typedef string POAManagerId change in POAManager string get_id(); to POAManagerId get_id(); Or better (see other issue). readonly attribute POAManagerId the_id;
A lot of the methods on the POA which have USE_DEFAULT_SERVANT or USE_SERVANT_MANAGER as policies don't describe in detail what should happen when one of these policies is set, but no default servant/servant manager is set. For example reference_to_servant, when USE_DEFAULT_SERVANT is set and default servant is registered we return the default servant, but what when no default servant is set, is then the ObjectNotActive the correct exception? Shouldn't this be something like a system exception (bad inv order, obj adapter or something like that?)
this section says: // GIOP 1.0 struct LocateRequestHeader_1_0
{ // Renamed LocationRequestHeader unsigned long request_id; sequence <octet> object_key; }; Anonymous types are deprecated so this struct has to be updated
The spec should define a standard CompressorId for zstd (see https://en.wikipedia.org/wiki/Zstandard)
We propose to extend the InvalidName exception with a "string name" member to simplify analyzing problems when this exception is thrown, the exception will tell at that moment the name that failed
Currently CCM uses a Cookie which is returned from the connect operations which has to be pased with disconnect. This requires the deployment tooling to store this Cookie at deployment for usage later on at teardown. As each connection has a unique string id in the plan we propose to replace the Cookie with the unique string id which is from the deployment plan. With a connect this string is passed with the connect call, later on with disconnect the same string can be passed again. For all calls that retrieve a struct containing a Cookie we propose to replace this with a IDL map with the string as id , the reference as second value.
These changes make deployment logic/tooling much easier, also now a IDL map is used which makes user code more clean instead of emulating a map with a sequence with a struct where the user has to search themselves.
It would be a much easier API for the user when ConfigValues would be a IDL map of FeatureName and a any
The CCMHome interface does not provide a mechanism for obtaining references to all CCMObjects that the home has created (those that have not been removed). The lack of a method to get all the components created by a home is inconsistent with other sections of the CCM model (specifically the deployment module APIs). Furthermore, this method would be very useful as it would provide a mechanism for querying a Container for all existent components.
Resolution:
Replace the following text in formal/02-06-05 on page 1-41
interface CCMHome
{ CORBA::IRObject get_component_def(); CORBA::IRObject get_home_def (); void remove_component ( in CCMObject comp) raises (RemoveFailure); };
with
typedef sequence<CCMObject> CCMObjects;
interface CCMHome
{ CORBA::IRObject get_component_def(); CORBA::IRObject get_home_def (); void remove_component ( in CCMObject comp) raises (RemoveFailure); CCMObjects get_components(); };
and add the operation description
get_components
The get_components operation returns a sequence of all existent CCMObject references (i.e. those that have not been removed) created by this CCMHome.
Document formal/02-06-05 on page 1-49 states the following:
"The implementation of a component type's home object may optionally support the
HomeConfiguration interface. The HomeConfiguration interface is derived from
Components::CCMHome. In general, the HomeConfiguration interface is
intended for use by an agent deploying a component implementation into a container,
or an agent deploying an assembly."
The first statement does not offer a clear interpretation when considering the language mapping for homes. If the implementation of a component type's home optionally supports HomeConfigurator how is this information defined in IDL? Should the component type's home definition support HomeConfiguration? This would seem to be the proper interpretation but that leads to problems in the language mapping of the defined home. In section 3.3.3.6 on page 3-45
Home Explicit Executor Interface
The home explicit executor callback interface is defined by the following rules:
1. For each home <home name>, a local explicit executor interface with the same
name as the home, but with a prefix of "CCM_" and a postfix of "Explicit" is
defined.
2. The explicit executor interface contains all attributes and operations declared by the
home.
3. If the home has a base with a name of <base name>, the explicit executor
interface inherits CCM_<base name>Explicit. If the home does not have a base,
the explicit executor interface inherits Components::HomeExecutorBase.
4. If the home has supported interfaces, they are inherited by the explicit executor
interface.
5. Additional operations are added to the explicit executor interface for factories and
finders, see below.
Item 4 would imply that the home explicit executor must include operations defined in both HomeConfigurator and CCMHome since HomeConfigurator extends CCMHome. This is clearly not the intended behavior of the home explicit executor since it specifically excludes any direct inheritance of CCMHome.
Resolution
The inheritance of CCMHome by HomeConfiguration should be removed since it is implied that every home will extend CCMHome and home definitions in IDL would then be able to explicitly support HomeConfiguration without the extra baggage of the CCMHome interface. Furthermore, the language mapping does not properly handle a component home that supports HomeConfiguration (if it extends CCMHome) since the component executor would include all CCMHome operations. The language mapping would work fine if HomeConfiguration did not extend CCMHome.
Replace text in formal/02-06-05 on page 1-49
The implementation of a component type's home object may optionally support the
HomeConfiguration interface. The HomeConfiguration interface is derived from
Components::CCMHome. In general, the HomeConfiguration interface is
intended for use by an agent deploying a component implementation into a container,
or an agent deploying an assembly.
with
The implementation of a component type's home object may optionally support the
HomeConfiguration interface. In general, the HomeConfiguration interface is
intended for use by an agent deploying a component implementation into a container,
or an agent deploying an assembly.
Replace IDL in formal/02-06-05 on page 1-49
module Components {
interface HomeConfiguration : CCMHome
;
};
I propose to introduce generic operations that allow
interconnecting ports regardless of their type. This
would ease generic programming.
The first part of the proposal is to allow generic
usage of the "connect" and "disconnect" operations
that are (currently) in the Receptacles interface,
i.e. to extend the functionality to not only work
on receptacles, but also on event source ports
(emits and publishes keywords).
The names "connect" and "disconnect" are appropriate
for any kind of port, and their signatures are the
same as "subscribe" and "unsubscribe" in the Events
interface.
The second part of the proposal is to introduce a
new operation "get_port" into the CCMObject interface.
This operation would take a FeatureName parameter and
return the object reference associated with that
facet or event sink.
So I propose the following steps:
1.) Allow connect, disconnect and get_connections to
operate on event source ports, and introduce a
get_port operation.
This change would be backwards compatible.
2.) Move connect, disconnect and get_connections from
the now inappropriate Receptacles interface into
the CCMObject interface. This step might cause
minor, easily fixable breakage for software that
widens an object reference to Receptacles instead
of CCMObject. (I don't think any such software
exists, it's more of a theoretical issue.)
3.) Discourage, then remove the "subscribe" and
"unsubscribe" operations in the Events interface.
They don't offer any more type safety than connect
and disconnect.
I believe that these changes would also be of interest
for slimming down CCM for the Lightweight CCM RFP, and
in light of the Streams for CCM RFP (which will likely
add another port type that needs interconnecting).
This change does not have any impact on component
implementations. The change to CCM implementations
(ORBs) is neglegible (I would expect a day to make
these changes in MicoCCM, another day to test them).
If there is general agreement on this issue, I will
draft the text updates.
For the optional mapping example a `void age(IDL::optional<float>&&)` is lacking, like described for some types in chapter 6.14
For the example code, for the setter, the std::optional should be passed as const&, see https://stackoverflow.com/questions/69277649/does-passing-an-stdoptionalt-by-reference-actually-save-copying
Within the text of chapter 6.31/6.32 (IDL4) all C++/IDL should use a different font to make it clear it is code, just as in the other chapters.
For anyone using the class mapping of a structure the spec should also provide a class mapping for a bitset, that way they have a consistent API. Also why is a inherited bitset not mapped to C++ inheritance, by removing the inheritance the inheritance relation can't be used in C++ also
In the case of Mnemonic Value Request Message and Archive Mnemonic Value Request Message, the requestor can specify a STOP-TIME or DURATION, but both are optional. If neither is specified, the subscription is open-ended with no knowable end, until the requestor sends a 'STOP' message. In order to avoid infinite fulfillment of a subscription to a potentially lost requestor, we could enforce a concept that a requestor must specify either a STOP-TIME or Duration.
In practice, this is an inadequate requirement, since a caller could specify a very long duration, like 1000 years, and circumvent the desire of this issue.
However, this is issue simply captures the idea to promote further discussion.
With the advent of the C2MS Message Envelope, some tracking or meta-data fields exist in both the new Message Envelope and in the already-existing C2MS Message. For now, it is the case that we want to leave fields in the C2MS message and encourage migration toward Message Envelope usage. In a follow-on release, the duplicated fields should be deprecated in the C2MS Message.
Changes need to be made to the "Additional Information" tables that contain Field listing for each message. The necessary changes are to provide complete information and to unify the names of the column headers across all messages.
Should add a type column to the fields table "Additional Info". Currently, the only indicator of type is in the UML diagram. Because of this, it is often the case that a reader of the table, must glance at the UML diagram in addition to reading the table.
Additionally, the tables are not uniform within the 1.0 document. Some use "Value" for a certain column header, while others use "Value/Description". To resolve this, it would be useful to use "Value" in every table and to rename the current "Notes" column to "Description" which is more accurate.
Many fields in the C2MS Header (which have of necessity also been put in the C2MS Envelope) should be evaluated for change or removal in the next major release. Change to be made in both C2MS Message and C2MS Envelope. Examples:
Issue C2MS11-54, already approved, has removed two subject elements that didn't belong in Telemetry TDM Frame Message. In fact, there are many more similar irregularities across all the Telemetry messages.
The needed changes are described below, but also shown in the attachment (original and revised) that shows the fields and subject elements as they exist today and should be after corrected.
Some fields and message elements that should be required are listed as optional. For example, in the Telemetry CCSDS Packet Message, ME SCID was added in 1.1, so had to me marked optional, but it should be required. APID already existed in that message as a Message Element, but not as a field, so whereas the ME is required, the field had to be made optional (for backward compatibility).
Additionally, in section 6.2.2 Format of C2MS Subject Names, there is a description that says, "If an element is required but not applicable for that mission or to that type of message, the publisher inserts “FILL” (no quotes) for that element." However, this should be cleaned up. If a field is required it should be required, if not, then it should not be required. Need a run through the messages to see how this can be improved.
Some Message Elements and Fields are in different order from message to message. The fields are just a listing so not as important, but the MEs are order-dependent. One example of how this is an issue is that the Telemetry CCSDS Packet Message added a new ME, but this had to go to the end (ME6) because of backward compatibility. This creates a strange ordering with VCID, APID, Collection Point, SCID. This is just one example, but the need is to evaluate all the MEs and fields and see if any need to be moved to make messages more uniform in structure.
Additionally, there are cases where some MEs have been removed between 1.0 and 1.x, leaving "not used"/"FILL" in the corresponding positions of MEs and these need cleaning up.
Tracking fields do not specifically belong in a C2MS Message. Rather, there should be a message envelope that contains these fields for the purpose of delivering a contained C2MS message. This "Message Envelope" is the logical place for managing tracking fields and other metadata related to, but not part of a C2MS message body.
This is clear when considering tracking fields, MW-INFO and CONNECTION-ID, which are message-bus handling constructs and have no meaning related to C2 of a satellite.
Note that this concept was originally moved to C2MQ. However, because C2MQ is a long way away and because message envelope is a useful construct within C2MS, it was determined at the Austin (Dec, 2023) C2MS meeting to bring this back in to C2MS and take the envelope concept out of C2MQ (leaving it to cover service-based interactions outside of the messages). Therefore, this is a re-entry of the envelope mechanism.
As part of this effort, we should do the following:
Add fields that allow encryption of content sections of the C2MS message body as well as message signatures or message authentication codes. This would not assume or provide any particular mechanism to encrypt/sign, but would allow for tracking of these fields to aid usage.
The benefit of doing this is to allow the Mission to determine levels of security and secure componentry, but to use the message definition as a way to track this information.
Using the value ESTIMATED for both accuracy_derivation_type and navigation_derivation_kind_type causes problems in some programming languages; it is also better practice to be more descriptive.
Using the value ESTIMATED in accuracy_derivation_type and navigation_derivation_kind_type causes problems when mapped to some programming languages; it is also better practice to be more descriptive.
Replace simple service REQ/RESP and deprecate current simple service messages.
Numerous issues are present with the current Simple Service REQ/RESP Messages. These include:
Together, this makes the Simple Service Messages hopelessly tangled. The effort here is to start from scratch, deprecate the existing messages and move forward with something more workable.
In this there are two factors that need consideration:
UNIQUE-ID in the Header is of type Header String (to be Subject Token String due to C2MS11-49). According to table 8-3: "Globally unique ID – reserved for use by implementation (PSM)". Note that a "Header String" is limited to upper and lower alphanumeric plus '-' and '_'. Recommendation of C2MS is that best practice is to keep Header String to no more than 12 characters.
So, Header String or Subject Token String isn't the right type.
I think we need to know what GMSEC uses for a type of UNIQUE-ID. But, it possible, it would be good if it was a GUID, relating to C2MS11-16.
After discussion in C2MS RTF in Orlando 2023 Tech Meetings, we determined to clarify or clean up some text with Simple Service Request and Response messages as follows:
Note that the response message as it is lacks the Service-Group that was specified in the request message. This lack makes it impossible to correctly correlate a response to a request that did specify Service-Group. However, because we intend to 'rework' these messages in a future release, we won't make this change at present.
A related issue will be created to replace simple service and deprecate current simple service, but will be deferred to later.
Add field SERVICE-GROUP (String, Optional) to the message. ME2 should refer to this field for its value.
There are n+2 number of optional elements between ME4 and ME7. These fields map the field(s) PROD-SUBTYPE.n.NAME.
API Workaround: API only maps the first two of these product subtypes, and the user will have set subject if they want more.
Required C2MS Spec changes: Ditch the n+2 logic in the middle of a message subject and only display the first two PROD-SUBTYPE values in the subject (or FILL if not used). A subject that can have dynamically shifting positions of its subject elements has serious implications on compatibility.
From Justin: In the current specification, RAW-VALUE is limited to a 32-bit integer and EU-VALUE is limited to 64-bit float (i.e., double). These data types should be changed to allow larger data types to be represented (at a minimum, 64-bit integer should be supported throughout). May need a separate field to indicate the type of data in these fields.
[NOTE: the reason for deferment is simply say making the RAW-VALUE a 64 bit and the EU-VALUE 128-bit float falls outside of hardware support and programming language support -- and adding a DATA-TYPE field to support the specification of any valid c2ms data-type in either field seems like a big change that should be considered more fully.]
The current spec supports a RAW-VALUE and EU-VALUE (converted/calibrated) fields. Currently the RAW one is a 32-bit signed integer and the EU one is a double (64-bit). To support a broader value type and range, this change adds a RAW-VALUE-TYPE and an EU-VALUE-TYPE to any message these fields are in. In some cases, if the message has both a RAW and EU value, these could in some cases be identical. Additional optional (special case) fields are also added RAW-VALUE-LENGTH and EU-VALUE-LENGTH, these two are discussed below.
The RAW-VALUE-TYPE and EU-VALUE-TYPE would be one of the C2MS data-types and be valid for all samples in the message. Hence, they are only specified once per message.
For example, a typical combination might be: RAW-VALUE-TYPE=I32, EU-VALUE-TYPE=F64 for numeric calibrated telemetered values.
The main reason in some cases to preserve both the RAW and the EU value is that in some cases there's a need to re-calibrate existing values and the raw can then be used to do that... [are there any others?]
[It's worth noting that RAW here may mean literally bit-by-bit what's in the packet or it could mean "host corrected" (byte swapped) but without calibration -- we should sort that out. In fact, C2MS does not say that I can tell ... I'm aware that some orgs support the notion of raw from the packet, host-converted (byte/bit corrected), and fully calibrated) in which case within discussion we may want to have 3 fields, which seems excessive. I think I prefer 'host-corrected' for the raw, as we can only do so much, and some folks might not have the truly raw bits available anyway...]
RAW-FIELD-TYPE and EU-TYPE-TYPE are of type String. The legal values are specified in table 8.1 column Field-type. Note that these should probably be mixed character legal in these fields.
Two OPTIONAL fields are available for type binary (blob) and variable. These types SHALL supply RAW-VALUE-LENGTH and EU-VALUE-LENGTH which are both I32 and specify the number of bytes for either field value. Negative values are illegal. From an implementation point of view in regard to these variable length fields, that messages beyond a few megabytes are likely not supported.
Non-self-describing CCSDS attributes for either transfer frames or space packets should be provided as dependent attributes of the frame messages. This would enable full integration between a sender and receiver. Right now, whether these optional fields are provided is unknown, causing the proper rendering of the frame to not be possible without outside negotiation (beyond the specification).
Examples:
Frame Header Error Control of the AOS transfer frame (AOS Space Data Link Protocol (ccsds.org)), where nothing prior to it in the definition specifies whether it is there or not:
4.1.2.6 Frame Header Error Control
4.1.2.6.1 If implemented, Bits 48-63 of the Transfer Frame Primary Header shall contain the Frame Header Error Control. NOTE – The 10-bit Master Channel Identifier, the 6-bit Virtual Channel Identifier, and the 8-bit Signaling Field may all be protected by an optional error detecting and correcting code, whose check symbols are contained within this 16-bit field.
4.1.2.6.2 The presence or absence of the optional Frame Header Error Control shall be established by management.
4.1.2.6.3 If present, the Frame Header Error Control shall exist in every Transfer Frame transmitted within the same Physical Channel.
Space Packets and the secondary header (Space Packet Protocol (ccsds.org)): A space packet might have a secondary header with a variable length time code, a variable length ancillary data field, or both. A space packet might have a secondary header, a user data field, or both. The length is not specified for any of them. When present, the format of the time code can be one of several options, but which one is not specified:
4.1.3.3.3 Secondary Header Flag 4.1.3.3.3.1 Bit 4 of the Packet Primary Header shall contain the Secondary Header Flag. 4.1.3.3.3.2 The Secondary Header Flag shall indicate the presence or absence of the Packet Secondary Header within this Space Packet. It shall be ‘1’ if a Packet Secondary Header is present; it shall be ‘0’ if a Packet Secondary Header is not present. 4.1.3.3.3.3 The Secondary Header Flag shall be static with respect to the APID and managed data path throughout a Mission Phase. 4.1.3.3.3.4 The Secondary Header Flag shall be set to ‘0’ for Idle Packets
4.1.4.2.1.5 If present, the Packet Secondary Header shall consist of either: a) a Time Code Field (variable length) only; b) an Ancillary Data Field (variable length) only; or c) a Time Code Field followed by an Ancillary Data Field. 4.1.4.2.1.6 The chosen option shall remain static for a specific managed data path throughout all Mission Phases. NOTE – The format of the Packet Secondary Header is shown in figure 4-3. ANCILLARY DATA FIELD (optional) variable PACKET SECONDARY HEADER TIME CODE FIELD (optional) variable Figure 4-3: Packet Secondary Header
4.1.4.2.2 Time Code Field 4.1.4.2.2.1 If present, the Time Code Field shall consist of an integral number of octets. 4.1.4.2.2.2 The Time Code Field shall consist of one of the CCSDS segmented binary or unsegmented binary time codes specified in reference [3].CCSDS RECOMMENDED STANDARD FOR SPACE PACKET PROTOCOL CCSDS 133.0-B-2 Page 4-8 June 2020 NOTE – The time codes defined in reference [3] consist of an optional P-Field (Preamble Field), which identifies the time code and its characteristics and a mandatory T[1]Field (Time Field). Examples of time codes are CCSDS Unsegmented Time Code and CCSDS Day Segmented Time Code. Examples of characteristics are ambiguity period, epoch, length, and resolution. 4.1.4.2.2.3 The time code selected shall be fixed for a given managed data path throughout all Mission Phases. 4.1.4.2.2.4 If the characteristics of the chosen time code are fixed, the corresponding P[1]field (as described in reference [3]) need not be present. If the characteristics are allowed to change, the P-field shall be present so as to identify the changes. 4.1.4.2.2.5 The presence or absence of the P-field in the Time Code Field shall be fixed for a given managed data path throughout all Mission Phases. If present, it shall immediately precede the T-field that is defined in reference [3]
4.1.4.3 User Data Field 4.1.4.3.1 If present, the User Data Field shall follow, without gap, either the Packet Secondary Header (if a Packet Secondary Header is present) or the Packet Primary Header (if a Packet Secondary Header is not present). 4.1.4.3.2 The User Data Field shall be mandatory if a Packet Secondary Header is not present; otherwise, it is optional. 4.1.4.3.3 If present, the User Data Field shall consist of an integral number of octets. 4.1.4.3.4 If the Packet is not an Idle Packet, then the User Data Field shall contain application data supplied by the sending user. If the Packet is an Idle Packet, the User Data Field shall contain Idle Data. NOTE – The bit pattern of Idle Data is set by the mission and is not specified in this Recommended Standard
4.1.4.3 User Data Field 4.1.4.3.1 If present, the User Data Field shall follow, without gap, either the Packet Secondary Header (if a Packet Secondary Header is present) or the Packet Primary Header (if a Packet Secondary Header is not present). 4.1.4.3.2 The User Data Field shall be mandatory if a Packet Secondary Header is not present; otherwise, it is optional. 4.1.4.3.3 If present, the User Data Field shall consist of an integral number of octets. 4.1.4.3.4 If the Packet is not an Idle Packet, then the User Data Field shall contain application data supplied by the sending user. If the Packet is an Idle Packet, the User Data Field shall contain Idle Data. NOTE – The bit pattern of Idle Data is set by the mission and is not specified in this Recommended Standard
TLM and MVALs can be retrieved from the archive, but it would be useful to define a way to retrieve archived Commands and Events as well, since these represent, along with TLM, the SatOPs messages.
From Justin: The REQUEST-ID field was defined as a U16. Recommend this field be changed to be a string to allow it to be utilized as a GUID. This allows it to work better for transport of existing interfaces that utilize a GUID to ensure message uniqueness, especially when multiple instances of the application are running concurrently.
Due to lack of the ability to have multiple independent implementations of GMSEC due to its message-building API functions in source code, it would be appreciated if there were an XML PSM available. This would allow for an independent implementation apart from the single known implementation at this time. At this time, there is no known PSM that enables implementation of C2MS at this time that does not depend on FOSS or government-licensed IP.
This is based on inputs from C2MS-2.
The C2INav Model refers to a package defined by OARIS 1.1.
OARIS 2.0 is about to be published and there are 2.1 RTF & 3.0 FTF in progress.
The "Publish" MEP second paragraph talks about using either MSG or REQ messages as a means of publishing. I think this could use some revisiting.
It seems on that a REQ message "may or may not require a response. For example, one component may request another component to take some action and does not need to know immediately if the action was successful or not." f(section 6.3.2.1, pg 15). This is then enabled by specifying a BOOLEAN value for "RESPONSE" indicating whether a reponse is expected in a REQ message.
To me, it seems like not expecting a response when issuing a REQ message is a corner case. Even in the example above, how do I know that ANY component received the REQ? I would prefer to say that components that process a REQ message are expected to respond AT LEAST with a RESP Message acknowledging receipt. If the sender chooses not to look for one, fine, but it seems like an odd pattern to make a request and ignore whether anyone heard you.
This would aid in simplifying the Publish MEP to reduce it to just MSG. Actually, if we don't do this, we need to fix the sequence diagram on pg 24, anyway, because as shown it's incorrect; requiring sending a MSG before sending a REQ. It's really meant to be either-or. So, if we remove REQ as a Publish mechanism, the diagram will be adjusted to be correct. If we don't remove it, we need to split the SD into two separate diagrams.
With all this in mind, I'd suggest:
Note that if we remove "RESPONSE:BOOLEAN" concept, this affects the following:
8.4.1.3 Directive Request Contents
8.10.1.3 Command Request Message Contents
8.12.1.3 Simple Service Request Message Contents
Additionally, we'd need to look for scattered text in the spec that says REQ does not require a response.
For the Archive Mnemonic Value Request Message, under the explanatory text, there is a paragraph stating:
"Optionally, if known or applicable, the requestor can specify the file type and file attributes with the optional dependent fields under the Output Product Category and Output File Attributes sections."
I'm not sure what this is referring to. There are no Product Category or Output File Attributes dependent fields in the Message. The terms "Output Product Category" and "Output File Attributes" occur in the document only in this paragraph.
The text either needs to be clarified or removed.
Almost all miscellaneous subject elements for messages are specified as mapping to fields in the message. But a few are not. For example, see the Miscellaneous Elements table 8-46 for the Control message. The elements DESTINATION_NODE and DESTINATION_FACILITY do not exist as fields in the message. (Note: it may be more appropriate to add some of these fields to the Message Header rather than many/most messages.) In this particular example, this may be resolved by C2MS11-28, but each message type would need to be evaluated to see what other subject elements are not mapped to fields.
Document clarification: The DDD portion of the Time Type, as shown in table 8-2 on page 40, has a range of 1-365 (or 366). But when using a relative time (by preceding the value with a "+" or a "-"), the DDD portion can contain a zero value. Make this clear and add a couple more relative time examples.
Consider replacing C2MS invented date format with RFC3339 or ISO8601 to include relative time.
Many fields in many messages contain value information. Some of the values are defaults and some are intended to be constant. Also, this information is in the "notes" column. There should be a way to differentiate between fixed and default values more easily than reading the notes fields. Also, this will make encoding those attributes in the .xsd PSM easier.
In the Command Request Message, the Binary "CMD-DATA" message contains the packet/fram/CLTU, etc, for all CMD-FORMAT types. However, if the CMD-FORMAT type is MNEMONIC this doesn't make as much sense.
Suggestion here is to create a new field in Command Request Message, "CMD-MNEMONIC" as type STRING to hold the human-readable MNEMONIC for command lookup if the CMD-FORMAT is of type MNEMONIC.
In this way, both CMD-DATA and CMD-MNEMONIC would be Dependent fields, with usage based on the contents of CMD-FORMAT.
RTF proposed (Burlingame, 2022) to do a second message type for MNE types, with 0-n parameters, each parameter specifying a type. Mike to create proposal text.
We have previously approved C2MS11-55 that changes the concept of REQUEST-ID as Replacement. After reviewing this change with the EGS Team, it is apparent that we could tighten up some of the text in the proposed change to make it more clear what are valid second-uses of REQUEST-ID and what are invalid, along with the expected response to an invalid use.
It should be invalid in Replay Telemetry or MVAL Request to issue a start after a start has already been done using the same REQUEST-ID. In Replay Telemetry, we probably need to think about it. If an invalid re-use of REQUEST-ID is sent in a request message, an indicator should be returned in a response for Invalid Request.
The Subject for TLMTDM Frame Messages includes the following:
-ME3 = VCID
-ME4 = APID
However these fields:
a) don't exist in the TLMTDM Frame Message, so can't be populated to the message subject,
b) belong only to CCSDS frames, not TDM frames.
These Message Subject Miscellaneous Elements should be removed and replaced with "FILL" to preserve ME5 as Collection Point.
The APID is associated with a telemetry packet, not the frame.
The APID is associated with packets, not the telemetry frame.
This value is used in the subject, so should be added to the message.
(NOTE: do NOT add this field to the CCSDS Frame message; TBD for Processed Telemetry Message and TDM Frame message. Also, check the VC ID usage appropriateness in all 4 TLM messages.)
Mnemonic Value Request Message and its corresponding Mnemonic Value Response Message utilize a concept called "ONESHOT" or "Oneshot". These are the only messages in C2MS that have this construct.
This is described in Mnemonic Value Request Message as:
"The Mnemonic Value Request Message is used to request one or more mnemonics either as a single sample ('Oneshot') or as a request to Start publishing the mnemonics continuously."
and
Mnemonic Value Response Message:
"For a 'Oneshot' Mnemonic Value Request Message, the Mnemonic Value Response Message contains the values of the requested mnemonics and no further Mnemonic Value Data messages will be published."
However, in a significant way, these statements conflict with the next line:
"For a 'Start' Mnemonic Value Request Message, the Mnemonic Value Response Message contains the initial values of the requested mnemonics and subsequent occurrences of the mnemonics will be published via the Mnemonic Value Data Message."
In other words, the Response Message will contain the initial set of data (current point values) in response to EITHER 'Start' or 'Oneshot'. The description says "either or" ("either as a single sample ('Oneshot') or as a request to Start publishing"), but the logical statement should be "yes and maybe" (Both Oneshot and Start will contain the initial set of data, but only Start will be followed with Mvals).
The effect of this is that the MVAL Req/Resp works in a primary subscription-based manner or in a different manner when specifying ONESHOT.
With this in place the MVAL Req/Resp sometimes follow the Request/Response Message Exchange Patter, and other times follow the Request/Response/Publish MEP. In fact, figure 8-19 Mnemonic Value Message Sequence Diagram illustrates the Request/Response/Publish MEP. It is not valid for the Request/Response MEP. No example of the Request/Response MEP is shown for this message.
Furthermore, some fields are handled specially depending on which MEP is used. For example, it is stated in the spec that when using ONESHOT, the following fields are ignored in the Request:
• PUBLISH-RATE
• DURATION
• MNEMONIC.n.CRITERIA
• MNEMONIC.n.SAMPLE-RATE
Meanwhile, in the Reponse, RESPONSE-STATUS field values 3 and 4, likely only apply to ONESHOT, while 1 likely only applies to non-ONESHOT. requests.
This odd dual-purposing of these messages was all likely done at some point out of convenience of overloading existing messages rather than creating new messages that would have been a more coherent design.
It has the effect, for a 'Start' of the consumer needing to read both the MVAL Return message for data and then a series of MVAL data message, rather than simply reading MVAL data messages.
In order to remove this overload, I suggest one of the following:
1 - deprecating ONESHOT and related fields in those messages and creating a new Message Type for retrieving current values. These could be called Mnemonic Current Value Request Message and Mnemonic Current Value Response Message.
2 - removing the value fields from the Response Message above, then simply convert the ONESHOT to a form of Request/Response/Publish MEP in which only one publish happens, and then the subscription ends. Subscription termination is already part of the spec, because of DURATION. The way this would work is the requestor sends a request message marked for ONESHOT, the service sends a response message, the service sends a single Mnemonic Value Data Message, the subscription is terminated. In this way, Mvals are only communicated in one message: Mval Data Message, easing the burden for handling two message types.
In a certain sense, I like the first option better, because it addresses the need to get current values using dedicated messages. However, the second approach is a much smaller change and represents a solution that is FAR more straight-forward than the way it is implemented today.
C2MS11-56, already approved, removed MNEMONIC.n.SAMPLE-RATE. In conveying this to the EGS Team, including MAV (NASA) and Ryan Conrad (MITRE) there was concern that we were losing fidelity with the data by only using PUBLISH-RATE to create messages but not having multiple samples at a rate of SAMPLE-RATE.
When we were considering this one, we approached it from the perspective that SAMPLE-RATE and PUBLISH-RATE created a dual-mechanism for when to send the MVAL message. While this is still and issue, there may be a way to allow both desired results in a combined way.
One concern of both the C2MS Team and the EGS Team is in getting too many messages published. This is a clear concern with the SAMPLE-RATE, because of the CRITERIA's indication of "when data should be provided for the mnemonic", including on "Change". In fact, it's likely that CRITERIA is the suspect field basically determining how often to "provide" the data rather than SAMPLE-RATE.
Perhaps we could do the following:
Whatever we do, we need to revisit SAMPLE-RATE before finalizing 1.1.
According to the Command Echo Request:
“This message is nominally sent after a Command Request is processed by the final destination (e.g., antenna or spacecraft). The Command Echo Message can also be generated without a prior Command Request Message being sent; this is known as an 'unsolicited echo' and can be generated by ground station equipment as a result of the antenna receiving noise or interference.”
The concept of an unsolicited echo seems very strange, because it raises the question of what is being echoed, if it is not the command.
The Command Echo Message Additional Information table has a CMD-ECHO-RESULT value of UNEX "Unexpected echo received" which I suspect is tied to the "unsolicited echo".
If an unsolicited echo is meant to convey that the ground equipment is receiving noise or interference from the antenna, I believe a better approach would be to define a message to capture the noise or interference as an occurrence in the ground string and to send that, rather than to overload the Command Echo Message.
We have already added a CMD-ECHO boolean to the Command Request Message in C2MS11-87. However, there is a possible scenario where just because we asked for one, there is no way for one to be delivered.
According to C2MS11-87, the field is an attempt to "Indicate if an ECHO should be sent at any configured point(s) along the ground chain as the command is transmitted."
The question of this issue is around what to do if the back-end system is not capable of or is not configured to send an Echo. In that case, there would quietly be no echo at all in spite of setting that flag to true. Gerry has brought up that perhaps we need a message type that is "unable to echo" or use the CMD ECHO message with a value of "here's your echo, but we aren't able to collect any information".
Mnemonic Value Request Message and its corresponding Mnemonic Value Response Message utilize a concept called "ONESHOT" or "Oneshot". These are the only messages in C2MS that have this construct.
This is described in Mnemonic Value Request Message as:
“The Mnemonic Value Request Message is used to request one or more mnemonics either as a single sample ('Oneshot') or as a request to Start publishing the mnemonics continuously.”
and
Mnemonic Value Response Message:
"For a 'Oneshot' Mnemonic Value Request Message, the Mnemonic Value Response Message contains the values of the requested mnemonics and no further Mnemonic Value Data messages will be published."
However, in a significant way, these statements conflict with the next line:
"For a 'Start' Mnemonic Value Request Message, the Mnemonic Value Response Message contains the initial values of the requested mnemonics and subsequent occurrences of the mnemonics will be published via the Mnemonic Value Data Message."
In other words, the Response Message will contain the initial set of data (current point values) in response to EITHER 'Start' or 'Oneshot'. The description says "either or" ("either as a single sample ('Oneshot') or as a request to Start publishing"), but the logical statement should be "yes and maybe" (Both Oneshot and Start will contain the initial set of data, but only Start will be followed with Mvals).
As written, the text has to be read carefully to understand the "yes and maybe" logic. I suggest adding some supporting text to clarify this.
There is a STREAM-MODE in Replay Telemetry Message, but in this case, I believe what it is there for is to say what types of telemetry messages to replay. It's not part of the Subject, the way STREAM-MODE is for other messages. I'm not sure it makes sense in this message type and should be re-evaluated. At a minimum, beefing up the description of it would be helpful.
As part of C2MS11-14, which was already approved, there was a subtle inconsistency through its text and image changes. This issue is to capture the change for final submission of the documentation for C2MS 1.1.
In that issue, in the Configuration Status Message there is a field, NUM-OF-ASSOCS. It is marked optional in the diagram, but required in the text table.
In the Heartbeat Message, NUM-OF-SUBSCRIPTIONS is shown as optional, both in the diagram and in the text table.
In the Mnemonic Value Request Message, NUM-OF-MNEMONICS is shown as required, both in the diagram and in the text table.
In all cases throughout C2MS where there is a NUM-OF-[ITEMS] field, it should be required in the corresponding diagram and text table.
This is to align it with the obvious. The NUM-OF field indicates how many items are present in a set, such as MNEMONICS. If there are none, this field should simply be set to 0. However, if it were optional, that would mean that the field would either be present or set to 0. The former is preferred for clarity.
Simple Service Request uses ME1 to indicate the target of the request, but this can have one of two mutually-exclusive forms:
Meanwhile, the Simple Service Response also uses ME1 in a similar, but slightly different way. In the RESP, ME1 represents one of two mutually exclusive forms:
Note that when using ME1 to designate a component, it is always the target recipient of the request/response, but when specifying a Service Name, it is always the name of the Service Provided, which is more related to the responder than the requestor. In this way, the Request Message uses that form of ME1 to designate the recipient, but the Response Message in that form designates to the provider.
This dual-hatting of ME1 is pretty confusing. One major user of C2MS has modified these messages to separate out the two uses of ME1 into ME1 and ME2, shifting ME2 and ME3 to the right.
This issue reqeusts to do that same thing, matching the modification made by that major user.
In Mnemonic Value Request Message, there is a PUBLISH-RATE and there is a SAMPLE-RATE that can be specified for each MVAL. The correlation between these is somewhat open to interpretation. For example, the text of the SAMPLE-CRITERIA, associated with SAMPLE-RATE, says it drives "when data should be provided" which overlaps with the PUBLISH-RATE. If taking SAMPLE-RATE to be independent of PUBLISH-RATE, it means something else entirely.
The supporting text of the Mnemonic Value Request Message needs to make clear how these interact.
Note that we previously determined to remove SAMPLE-RATE due to perceived overlap, but have since decided to leave it in place and make clear its usage.
There is an already-accepted issue, C2MS11-56, that removed MNEMONIC.n.SAMPLE-RATE, but that issue did not address the related field, MNEMONIC.n.CRITERIA.
In that other issue, the MNEMONIC.n.SAMPLE-RATE was removed because it overlapped with the PUBLISH-RATE of the base message.
Since SAMPLE-RATE has been removed, one of the following additional steps needs to be taken:
Option A - remove the value "3 = Sample Rate" from MNEMONIC.n.CRITERIA
Option B - Remove MNEMONIC.n.CRITERIA completely for the same reasons SAMPLE-RATE was removed
Option B - Move MNEMONIC.n.CRITERIA to a field in the base message now to be called "PUBLISH-CRITEREA" with the following possible values:
1 = Change (value, flags, status) [publish when any MVAL experiences a change]
2 = Every Sample [publish when any new sample arrives for any MVAL]
3 = Publish Rate [publish at the rate specified in PUBLISH-RATE, already in the base message]
The bottom line is that just as in C2MS11-56, it doesn't make sense to have different publish/sample rates for the main message and each MVAL, so any of the above options are preferred over what it is in 1.0. (Mike: Personally, I like Option C).
A number of C2MS Messages include the concept of marking the mode of the data as “real-time (RT), replay (RPY), simulation (SIM), or test (TEST)” through a required field, STREAM-MODE.
The specific messages are:
• Telemetry CCSDS Packet Message
• Telemetry CCSDS Frame Message
• Telemetry TDM Frame Message
• Telemetry Processed Frame Message
• Replay Telemetry Data Request Message
• Attitude Parameter Message
• Attitude Ephemeris Message
• Orbit Parameter Message
• Orbit Mean-Elements Message
• Orbit Ephemeris Message
• Tracking Data Message
Where used, STREAM-MODE is a required field. A typical explanation in the C2MS Spec is that, “The STREAM-MODE field is used to classify the kind or source of the” message.
Although this may be useful in a closed experimental/engineering system, the concepts are not appropriate for an operational SATOPS system, where replay, test, sim data should never be mixed with real-world operational data. In a system with many components, the use of the STREAM-MODE field assumes that every component will properly handle the distinction for every message. As an example, a FireThrusters CMD message is received and the component fails to note that this particular message is a RPY STREAM-MODE and thinks to itself… ‘huh, I thought we fired thrusters, yesterday… but, OK, here it goes…”. In another example, a SelfDestruct CMD message is received and the component fails to note that the message is marked as TEST or SIM…
Instead of marking messages themselves, this type of distinction should be performed environmentally; one system is the operational system, other, separate systems are for simulation or test, another separate system performs forensics (replay). Keeping these purposed environments isolated from each other ensures that data never intermixes where not appropriate.
The resolution to this concern could be any of the following:
1. Remove the STREAM-MODE field — breaks backward compatibility, and affects any system already using this field. However, it represents a clean break from a field that should never be used in practice, anyway.
2. Make the STREAM-MODE field optional with default value assumed to be RT (real-time) and mark the field as deprecated (deprecated = should no longer be used and will be removed in a future major release) — maintains backward compatibility, but signals to users to cease using the field.
3. Make the STREAM-MODE field optional with default value assumed to be RT (real-time) and provide a best-practices statement; something to the effect of, “Although maintained for backward compatibility, the use of this field is strongly discouraged for operational systems, where test, sim, or replay data should never mix with real-world operational data” — this weakest approach leaves the use of the field in the hands of the user, but would be a bit embarrassing from the standpoint of a specification to preserve a capability that is strongly discouraged.
See attachment for non-exhaustive use in C2MS Spec.
Similar to C2MS11-43, this issue is to consider deprecating REQ-STRING in the Product Request Message. The desciption of the field is a bit different than in the Archive Request Message, so just needs some investigation to make sure that this message is still usable without the field.
The spec has the following sentence:
The _d discriminator modifier can only be used to set the discriminant to a value within the same union member.
This is not really clear and should be improved, maybe
The _d discriminator modifier can only be used to set the discriminant to a value that has the same union member as currently selected.
The spec has the following sentence:
The _d discriminator modifier can only be used to set the discriminant to a value within the same union member.
This is not really clear and should be improved, maybe
The _d discriminator modifier can only be used to set the discriminant to a value that has the same union member as currently selected.
The (primary) CMMN 1.1 XSD schema is published at this URL:
https://www.omg.org/spec/CMMN/20151109/CMMN11.xsd
which should be de-referenced from a URI such as:
https://www.omg.org/spec/CMMN/20151109/CMMN11/
Nevertheless, the schema itself is bound to a namespace:
http://www.omg.org/spec/CMMN/20151109/MODEL
which is not de-referenceable
It is possible that the schema and its namespace were published before OMG reorganized the URL/URI architecture and started to enforce de-referenceability.
Similar issues are likely to exist across the other CMMN schemas, and/or related specs such as DMN (1.1, 1.2)
It is not clear in the C2MS specification how to use/support the CMD-FORMAT=MNEMONIC on page 168. Explanation of the encoding should be provided to understand how to represent a command mnemonic and its arguments.
Based on review of latest specification, the problem detailed in C2MS-5 is still present. This problem makes it not possible for a client application to properly be developed to support all MEPs. If a client application is developed to support MEP2, then it will ignore all future responses after the first ACK comes in when communicating with a server that supports MEP4 or MEP5. If a client application is developed to support MEP4 and MEP5, then it will never think that a request finished when communicating with a server that supports MEP2.
As is currently specified, via table 6-9 on page 20, the Acknowledge is listed as a Final Status. Though it is only a final status in MEP2.
Possible solutions:
1. Remove MEP2. This would make Acknowledge in Table 6-9 have a Final Status of "No"
2. Add an additional status code of Acknowledge Complete (perhaps #7). In this option, Acknowledge (#1) would have Final Status of "No", though new Acknowledge Complete (#7) would have Initial Status of "Yes", Intermediate Status of "No", and Final Status of "Yes".
The Commons Ontology Library was recently published, and provides a set of classes and properties, such as identifier, that are more broadly useful than they are as embedded concepts in LCC. The LCC ontologies and reference data should be revised to reuse Commons rather than specifying these concepts and relationships locally.
What is a messaging router supposed to do if it receives multiple
requests from a client with more than one type of QueueOrderingPolicy
value? (Is this legal? Is it legal to have more than one QueueOrdering
bit set in a single request?) How can it sort on priority, FIFO, and
deadline simultaneously?
The CORBA specification has module SendingContext { //... interface CodeBase
{ //... CORBA::FullValueDescription meta(in CORBA::RepositoryId x); //... }; //... }; but there is no CORBA::FullValueDescription defined in the specification, yet the supplied <SendingContext.idl> file declares module SendingContext { //... interface CodeBase
{ //... CORBA::ValueDef::FullValueDescription meta(in CORBA::RepositoryId x); //... }; //... };
BTW I think the twiddle is incomplete because it is not reflected
in the BNF for Identifier. I think it is better if the BNF always
reflects the ultimate specification of a language's lexical
definition. Otherwise compiler writers are apt to miss the
subtleties.
I'll propose some BNF changes if others agree
There is a sentence in the first paragraph of 22.6 that should be fixed:
"The implementation of these methods must generate a method invocation
as described in Section 22.14, Message Routing, on page 22-50."
However, 22.2.5.3 allows asynchronous invocations to be delivered via
synchronous protocols if the RoutingPolicy is ROUTE_NONE.
This sentence should be changed to:
"The implementation of these methods may generate a method invocation as
described in Section 22.14, Message Routing, on page 22-50, depending
on the effective RoutingPolicy for the invocation."
What is the RSC when
> using a PersistentPoller? Since it is a valuetype that can be passed
> from one process to another, the RSC obviously can't be the same in the
> other process as at the original invocation point.
>
> Anybody have any bright ideas for this one? Should it be empty? A copy
> of the TSC at the poll point? Change MessageRouting:PersistentRequest
> to have an attribute that provides access to a copy of the RSC, and
> PersistentRequestRouter::create_persistent_request to have the RSC as an
> "in" argument?
CORBA 3, chapter 13.8, defines the Codec interface to encode
arbitrary data values into CORBA::OctetSeq "blobs" and vice
versa. This interface can be used, e.g., to supply and retrieve
ServiceContext data using the PortableInterceptor interfaces.
In practice, the Codec interface is also being used for data
serialization, i.e., to store and retrieve arbitrary values in
files or other databases.
However, the interface is deficient in that it does not consider
all possible variables that are needed for interoperability.
It supports setting the CDR version that is to be used, but
neglects byteorder and codeset settings.
Consequently, the encoded values are platform-specific. If a
value was encoded on a little-endian system, it will not decode,
or worse, decode erroneously, on a big-endian system. The same
caveats apply to codesets, e.g., when an ISO-8859-1 encoded
blob is decoded using UTF-8 or Windows-1252.
To support interoperability, the Codec interface needs to be
extended.
My recommendation is to extend the CodecFactory interface,
so that it supports creating CDR version-, byteorder-, and
codeset-specific Codec instances, either supplying user-
provided values for each, or informing the user about chosen
defaults.
Example:
module IOP {
const EncodingFormat ENCODING_DEFAULT = -1;
typedef short ByteorderFormat;
const ByteorderFormat BYTEORDER_DEFAULT = -1;
const ByteorderFormat BYTEORDER_BIGENDIAN = 0;
const ByteorderFormat BYTEORDER_LITTLEENDIAN = 1;
struct EncodingExt
{ EncodingFormat format; octet major_version; // set to 0 for default octet minor_version; ByteorderFormat byteorder; CONV_FRAME::CodeSetId char_data; // set to 0 for default CONV_FRAME::CodeSetId wchar_data; // set to 0 for default };
local interface CodecFactory
{ // create_codec remains as before Codec create_codec_ext (inout EncodingExt enc) raises (UnknownEncoding); };
};
The create_codec_ext operation would create an appropriate
Codec instance, if available; it will then set all "default"
members of the EncodingExt structure to their actual values,
so that the application can store this information along
with any encoded values.
One potential criticism of the above is that the encoding
format's parameters depend on the encoding format. For example,
there may be encoding formats that are byteorder-independent,
or that consistently use UTF-32 for strings, thus not needing
codeset parameters. Also, they may use wildly different
versioning. So a "better" solution might involve passing
the EncodingFormat, and an Any with a format-specific data
type.
That could look like:
module GIOP {
typedef short ByteorderFormat;
const ByteorderFormat BYTEORDER_DEFAULT = -1;
const ByteorderFormat BYTEORDER_BIGENDIAN = 0;
const ByteorderFormat BYTEORDER_LITTLEENDIAN = 1;
struct CDREncodingParameters
{ octet major_version; // set to 0 for default octet minor_version; ByteorderFormat byteorder; CONV_FRAME::CodeSetId char_data; // set to 0 for default CONV_FRAME::CodeSetId wchar_data; // set to 0 for default };
};
module IOP {
const EncodingFormat ENCODING_DEFAULT = -1;
local interface CodecFactory
{ // create_codec remains as before Codec create_codec_ext (inout EncodingFormat format, inout Any parameters) raises (UnknownEncoding); };
};
Once we have consensus on the approach, I will gladly volunteer
to come up with a full set of editing instructions
Related Specification: CommonObject Request Broker Architecture: Core Specification November 2002 Version 3.0 - Editorial edit to cover formal/02-11-03 Nature: Revision Subject: An extension of IOR to protect target objects Nature: Enhancement Issue Summary: IOR (Interoperable Object Reference) is the distributed reference of a CORBA object. The IOR of a target object is distributed to client applications that want to access the target object. Clients can easily connect to the target objects based on the location information in IOR. As a kind of object discovery scheme, IOR publishes some attributes related to target object, such as IP address, port number, internal object id, etc. As we know, many kinds of attacks can be performed to a target server when the IP address and port number of the target is exposed. The exposition of internal object id may also leads to security problems. We use Abstract IOR (AIOR) to make the originate IOR (we call it regular IOR) transparent to client applications, thus the target objects is protected from potential attacks. Proposed solution: We use proxy technology to protect target servers, following is the architecture of a typical scenario. Service Proxy (SP) acts as a portal for all background servers. SP will handle all requests from clients to background servers. So background servers are transparent to clients. ------------ ----------- | Client | Abstract IORs | Service | | application ---------------+ Proxy | | | | | ----------- --+ BS1's IORs | | | ------------------------- | | | BS2's IORs | | + ------------ | -------+ + BS3's IORs | Background | --------+ + | Server 1 | | Background | -------+ ---------- | Server 2 | | Background | ---------- | Server 2 | ----------- The core concept of the above architecture is Abstract IOR (AIOR). AIOR can be described by a simple equation: AIOR = SP's regular IOR + logical name Logical name is uniquely corresponding to an IOR of an object running on background server. So the SP should set up the mapping before corresponding request comes, and map the logical name in the AIOR to the regular IOR of the target object at background server for a coming request. The structure of AIOR is compatible to regular IOR. Firstly let's have a look at the structure of regular IOR defined at page 13-15. Then we will discuss how to support AIOR based on existing IOR data structures and what interfaces and methods will be defined. module IOP { // IDL // Standard Protocol Profile tag values typedef unsigned long ProfileId; struct TaggedProfile
; typedef sequence <TaggedProfile> TaggedProfileSeq ; // an Interoperable Object Reference is a sequence of // object-specific protocol profiles, plus a type ID. struct IOR
{ string type_id; sequence <TaggedProfile> profiles; }; // Standard way of representing multicomponent profiles. // This would be encapsulated in a TaggedProfile. typedef unsigned long ComponentId; struct TaggedComponent
{ ComponentId tag; sequence <octet> component_data; }; typedef sequence<TaggedComponent> TaggedComponentSeq; }; CORBA specification defines 3 standard IOR profiles (at page 13-17): module IOP
{ const ProfileId TAG_INTERNET_IOP = 0; const ProfileId TAG_MULTIPLE_COMPONENTS = 1; const ProfileId TAG_SCCP_IOP = 2; typedef sequence <TaggedComponent> MultipleComponentProfile; }; The following are standard IOR components that can be included in TAG_INTERNET_IOP and TAG_MULTIPLE_COMPONENTS profiles, and may apply to IIOP, other GIOPs, ESIOPs, or other protocols. An ORB must not drop these components from an existing IOR (at page 13-19). module IOP
{ const ComponentId TAG_ORB_TYPE = 0; const ComponentId TAG_CODE_SETS = 1; const ComponentId TAG_POLICIES = 2; const ComponentId TAG_ALTERNATE_IIOP_ADDRESS = 3; const ComponentId TAG_ASSOCIATION_OPTIONS = 13; const ComponentId TAG_SEC_NAME = 14; const ComponentId TAG_SPKM_1_SEC_MECH = 15; const ComponentId TAG_SPKM_2_SEC_MECH = 16; const ComponentId TAG_KerberosV5_SEC_MECH = 17; const ComponentId TAG_CSI_ECMA_Secret_SEC_MECH = 18; const ComponentId TAG_CSI_ECMA_Hybrid_SEC_MECH = 19; const ComponentId TAG_SSL_SEC_TRANS = 20; const ComponentId TAG_CSI_ECMA_Public_SEC_MECH = 21; const ComponentId TAG_ GENERIC_SEC_MECH = 22; const ComponentId TAG_FIREWALL_TRANS = 23; const ComponentId TAG_SCCP_CONTACT_INFO = 24; const ComponentId TAG_JAVA_CODEBASE = 25; const ComponentId TAG_TRANSACTION_POLICY = 26; const ComponentId TAG_MESSAGE_ROUTERS = 30; const ComponentId TAG_OTS_POLICY = 31; const ComponentId TAG_INV_POLICY = 32; const ComponentId TAG_CSI_SEC_MECH_LIST = 33; const ComponentId TAG_NULL_TAG = 34; const ComponentId TAG_SECIOP_SEC_TRANS = 35; const ComponentId TAG_TLS_SEC_TRANS = 36; const ComponentId TAG_ACTIVITY_POLICY = 37; const ComponentId TAG_INET_SEC_TRANS = 123; }; The following additional components that can be used by other protocols are specified in the DCE ESIOP chapter of this document and CORBAServices, Security Service, in the Security Service for DCE ESIOP section (at page 13-19, 13-20): const ComponentId TAG_COMPLETE_OBJECT_KEY = 5; const ComponentId TAG_ENDPOINT_ID_POSITION = 6; const ComponentId TAG_LOCATION_POLICY = 12; const ComponentId TAG_DCE_STRING_BINDING = 100; const ComponentId TAG_DCE_BINDING_NAME = 101; const ComponentId TAG_DCE_NO_PIPES = 102; const ComponentId TAG_DCE_SEC_MECH = 103; // Security Service The following is the description of our proposed supplement to CORBA core specification. We add one component into module IOP: const ComponentId TAG_AIOR_LOGICALNAME = XXX; // XXX is an undetermined ComponentId. The TAG_AIOR_LOGICALNAME component has an associated value of type string encoded as a CDR encapsulation. We have not defined the interface of mapping logical names to regular IOR because now this function is local and its interoperability is not necessary. But if two or more SPs want to exchange their mapping items to provide more intelegent services, we may need to define the coresponding interfaces.
The CORBA 3.0 spec adds the following note in Section 4.5.1: ORB Initialization.
"Whenever an ORB_init argument of the form -ORBxxx is specified, it is understood that the argument may be represented in different ways in different languages. For example, in Java -ORBxxx is equivalent to a property named org.omg.CORBA.ORBxxx."
The approach stated in the above note does not work for -ORBInitRef. For example, if you have
-ORBInitRef NameService=URL,
you cannot translate the above arguments into a property named "org.omg.CORBA.ORBInitRef" because there can be only one property of this name and there may be many different services. This issue was slightly cover by Issue 3643 (java-rtf), which was not resolved. This issue becomes obvious and important because the note added in the CORBA 3.0 spec.
Proposed solution: Arguments like "-ORBInitRef id=url" should be equivalent to a property named "org.omg.CORBA.ORBInitRef.id" with value "url".
The grammar definition for valuetype <state_member> via the rule
<declarators> includes <complex_declarator>.
It should be clarified whether valuetype state members are intended
to include <array_declarator>.
IMHO clarification is needed as state members are usually mapped
to accessor methods in programming languages. If permissible,
the accessor methods would return a complex type.
The "operation" field in the RequestHeader_1_2 struct is a string,
which implies that it should be subject to code set conversion. However,
existing practice seem to be that it is not converted, and there are other
factors which could make it difficult for implementations to convert it.
In addition, since the operation name is based on IDL/ASCII, conversion
doesn't necessarily make sense.
The easiest remedy would be to specify this as an exception in the
text of the spec. The "correct" remedy would probably be to change the
operation field from "string" to "sequence<octet>". This could cause
problems at some point, but it might not break too much since the CDR
encodings are the same.
REQUIREMENT
To be able to use interceptors, and in particular ForwardRequest, in a client to perform active, per-request, load-balancing.
PROBLEM
It is not possible to detect in an interceptor whether ForwardRequest has previously been thrown for the same client request. Thus it is possible for a client to go into an infinite loop throwing ForwardRequest.
DISCUSSION
The basic problem is that although for a single client request the request-scoped PICurrent is shared across across interceptor invocations - even when ForwardRequest is thrown - it is not possible to modify this information in an interceptor to indicate to a future invocation that the invocation has been seen. The two relevant parts of the spec here are:
21.3.6.5
For retries, depending on the policies in effect, a new request may or may not follow
when a retry has been indicated. If a new request does follow, while this request is a
new request, with respect to Interceptors, there is one point of correlation between the
original request and the retry: because control has not returned to the client, the request
scoped PortableInterceptor::Current for both the original request and the retrying
request is the same (see Chapter 21, Portable Interceptors on page 21-32).
21.4.2
Before an invocation is made, PICurrent is obtained via a call to
ORB::resolve_initial_references ("PICurrent")
From within the interception points, the data on PICurrent that has moved from the
thread scope to the request scope is available via the get_slot operation on the
RequestInfo object. A PICurrent can still be obtained via
resolve_initial_references, but that is the Interceptor's thread scope PICurrent.
See section 21.4.4.4, Request Scope vs Thread Scope on page 21-36 for a detailed
discussion of the scope of PICurrent.
Thus modifications to the thread's PICurrent are lost on retries and modifications to the request's PICurrent are not possible.
PROPOSED RESOLUTION
I have made several different attempts at coming up with a portable way of solving this problem without changing the spec, but have failed. It seems to me that it really should be possible for the interceptor to know that a retry is in effect and I can think of a number of different solutions to this:
1. add:
void set_slot (in SlotId id, in any data) raises (InvalidSlot);
to RequestInfo. This would allow interceptors to transfer information between invokes of the same client request and thus a retry could be detected.
2. Add a new function to RequestInfo to indicate that a forward is in operation. The minimalist fix here would be to allow forward_reference() to be accessed in send_request() as well as in receive_other(). i.e. returning the object from the previous ForwardRequest if that has been thrown.
I'm ambivalent about which of these is best but for the sake of simplicity I'm going to plump for (1) because this is already allowed in ServerRequestInfo.
So:
During the interceptor FTF we changed the server-side threading
requirements such that all server-side points run in the same thread
as the ServantManager and servant except receive_request_service_contexts.
We attempted to update 21.4.4.4 "Request Scope vs Thread Scope"
accordingly but knew we screwed the picture and wording up. So we
punted to the RTF.
The main problem with the current wording is that is forces a copy of
of TSC/RSC before the servant manager and then receive_request are
called. This is necessary because 21.4.4.5 item 5 says: "The
receive_request points may modify the RSC, but this no longer affects
the TSC."
The only way to make RSC identical to TSC in receive_request with
respect to reading but also have them be independent with respect to
writing is to make a copy (which could be optimized to copy-on-write,
but why?).
I suggest we just state they are equivalent after
receive_request_service_contexts.
Here is a proposed revision to ptc/00-08-06 along these lines.
Comments?
Harold
21.4.4.4 Request Scope vs Thread Scope
... On the server-side, the request scope PICurrent is attached to
the ServerRequestInfo and follows the request processing. It is
logically equivalent to the thread scope PICurrent after the list of
receive_request_service_contexts interception points are processed.
21.4.4.5 Flow of PICurrent between Scopes
5. The ORB logically makes the RSC equivalent to the server-side TSC
after the receive_request_service_contexts points are processed and
before the servant manager is called. This TSC is within the context
for both the receive_request points, the invocation of the servant
manager, and the invocation of the target operation.
The receive_request points are called. These points have access to the
RSC. Modifying the RSC at this point makes corresponding
modifications on the TSC. Since these points execute in the same
thread as the target operation invocation, these points may modify the
server-side TSC which makes corresponding modifications on the RSC.
6. After the receive_request points are called, control transfers to
the server threads which may also read and write this server-side TSC.
Any modifications to the TSC makes corresponding modifications on the
RSC.
7. <No change>
8. <DELETE THIS ITEM>
9. The send interception points have access to the RSC (and the
equivalent TSC) from which they may populate the reply service context
list. After the invocation result is sent back to the client, the
server-side RSC is logically destroyed.
...
The picture would also need updating, but let's agree on wording first.
Since there doesn't appear to be a CosNaming mailing list this seems like as good a forum as any this discussion.
It has long struck me that the use of CosNaming for JNDI in J2EE applications creates a significant outage in being able to bind and retrieve objects that are not remote (see the EJB 2.0 spec for details). In JNDI you can bind pretty much anything that is Remote (aka an Object reference) or Serializable (aka a valuetype), however CosNaming only allows you to do the former.
One easy way to solve this would be to create a new NamingContext extension that allows one to bind and resolve Any's. This is in keeping with the Java-to-IDL spec's treatment of untyped Java objects and at the same time would not compromise non-java implementations. For JNDI it would only be necessary to support Any's containing:
1. Object references
2. valuetypes
3. valueboxes
An exception could be thrown for any other types. The candidate interface might look something like this:
module CosNaming {
interface NamingContextAny : NamingContextExt {
exception TypeNotSupported {};
void bind_any(in Name n, in any obj)
raises (NotFound, CannotProceed,
InvalidName, AlreadyBound, TypeNotSupported);
void rebind_any(in Name n, in any obj)
raises(NotFound, CannotProceed, InvalidName, TypeNotSupported);
any resolve_any (in Name n)
raises (NotFound, CannotProceed, InvalidName);
any resolve_str_any(in StringName n)
raises (NotFound, CannotProceed,
InvalidName, AlreadyBound);
};
};
The implementation of this interface in Java is trivial, although perhaps less so in other languages. Whether or not that matters is open to question.
The Portable Object Adapter and Portable Interceptors both are able to
raise a ForwardRequest exception to allow redirection to another
object.
What happens if the ForwardRequest is to a local object?
Is this even possible?
Should it be allowed?
I suggest we change the specification to make this illegal.
The rule number (85) is indented, the rule number is not aligned with other rule numbers.
The overhead of processing TaggedComponents within an IOR becomes
significant when done many times, as in the case of J2EE
implementations where multiple interceptors are used.
The definition of IORs in the IOP module is intended to support
transmission and interoperability, rather than efficient access to the
local, ORB specific, internal structure.
I would like to propose that an abstract model of an IOR is introduced
which recognises that many of the constituent parts of IOR profiles are
identical for different objects, along the following lines:-
with corresponding IDL definitions that allow the language bindings
to optimise conversion between transmission and internal IOR formats
to provide a performant and natural interface for IOR access.
Rationale:
In Java, for example, it should be possible to manipulate IOR
TaggedProfiles and IIOPProfileTemplate TaggedComponents using the
facilities of the Java collections framework, or at least some
equivalent facility that is a natural Java idiom.
Templates can be used to create IIOPProfiles because the basic object
adapter model for object creation is to establish many of the properties
of an IOR when the object adapter is created.
TaggedProfile and TaggedComponent are intended as frameworks that may be
extended to support application defined tagged profiles and components.
To support this it is necessary to be able to register TaggedProfile and
TaggedComponentFactory instances with an ORB, in which case any IOR
unmarshalled by that ORB instance will use the registered factory
to unmarshal the tagged profile or component.
Since there has already been quite a bit of discussion about this in the
Java RTF, here is a proposal for review:-
Proposal:
21.5.2 An Abstract Model for IORs
To support efficient access to IORs, avoiding repeated marshaling and
demarshaling of IOR components, it is helpful to have an abstract model
of the, ORB specific, local representation of an IOR.
Recognising that many of the constituent parts of IOR profiles are
identical for different objects allows the following model to be
defined:-
21.5.3 Local IOR Interfaces
The following interfaces provide access to the data within a local IOR
using this model.
TaggedProfile and TaggedComponent are generic interfaces. Users of the ORB
may create implementations of them. Corresponding factories may be
registered with the IORFactory.
The IORFactory is obtained through a call to
ORB::resolve_initial_references ("IORFactory") and may also be used to
obtain an IOR for an Object.
An ORB must return all tagged profiles in an IOR through the IOR
getProfiles operations. The ProfileIterator interface allows a client
to iterate through the TaggedProfiles using the next operation.
Those profiles whose ids have a registered TaggedProfileFactory will
be made available in the form returned by the registered factory's
TaggedProfileFactory create operation, which must return a subtype of
TaggedProfile.
An ORB will provide a TaggedProfileFactory implementation for the
IIOPProfile.
Profiles with ids for which no TaggedProfileFactory has been registered
will be made available as instances of a generic ORB implementation of
TaggedProfile.
Similarly, an ORB must return all tagged components in an IIOP profile
through the IIOPProfile().getTemplate().getComponents() operations.
The ComponentIterator interface allows a client to iterate through the
TaggedComponents using the next operation.
Those components whose ids have a registered TaggedComponentFactory
will be made available in the form returned by the registered factory's
TaggedComponentFactory create operation, which must return a subtype of
TaggedComponent.
Components with ids for which no TaggedComponentFactory has been
registered will be made available as instances of a generic ORB
implementation of TaggedComponent.
module PortableInterceptor {
local interface TaggedComponent
{ readonly attribute IOP::ComponentId component_id; readonly attribute CORBA::OctetSeq component_data; IOP::TaggedComponent convert(); };
local interface ComponentIterator
{ TaggedComponent next(); boolean has_next(); };
local interface TaggedProfile
{ readonly attribute IOP::ProfileId profile_id; readonly attribute CORBA::OctetSeq profile_data; IOP::TaggedProfile convert(); };
local interface ProfileIterator
{ TaggedProfile next(); boolean has_next(); };
local interface IOR
{ readonly attribute string type_id; ProfileIterator get_profiles (); ProfileIterator get_profiles_by_id (in IOP::ProfileId profile_id); };
local interface IIOPProfileTemplate
{ readonly attribute IIOP::Version iiop_version; readonly attribute string host; readonly attribute unsigned short port; ComponentIterator get_components(); ComponentIterator get_components_by_id (in IOP::ComponentId id); };
local interface IIOPProfile:TaggedProfile
{ readonly attribute CORBA::OctetSeq object_key; readonly attribute IIOPProfileTemplate profile_template; };
local interface TaggedComponentFactory
{ readonly attribute IOP::ComponentId factory_id; TaggedComponent create_tagged_component (in CORBA::OctetSeq component_data); };
local interface TaggedProfileFactory
{ readonly attribute IOP::ProfileId factory_id; TaggedProfile create_tagged_profile (in CORBA::OctetSeq profile_data); };
local interface IORFactory
{ IOR create_ior (in Object obj); void register_tagged_profile_factory (in TaggedProfileFactory tpf); void register_tagged_component_factory (in TaggedComponentFactory tcf); };
};
21.5.3.1 IOR Factory Interface
create_ior
Return an IOR relating to the given Object.
If create_ior is invoked when the object reference is not bound,
standard system exception BAD_INV_ORDER with minor code n will be
raised.
register_tagged_profile_factory
Register a TaggedProfileFactory to create TaggedProfiles with the id
returned by the given factory's getId method. If a TaggedProfileFactory
already exists for the given id, standard system exception
BAD_INV_ORDER is raised with a standard minor code of n+1.
Instances of this interface may be defined by users to support custom
tagged profiles.
register_tagged_component_factory
Register a TaggedComponentFactory to read TaggedComponents with the id
returned by the given factory's getId method. If a
TaggedComponentFactory already exists for the given id, standard system
exception BAD_INV_ORDER is raised with a standard minor code of n+2.
Instances of this interface may be defined by users to support custom
tagged components.
21.5.3.2 IOR Interface
This interface gives access to a local representation of an
IOP::IOR.
type_id
The type id string from the IOR.
get_profiles
Returns an iterator over the TaggedProfiles within the IOR.
get_profiles_by_id
Returns an iterator over the TaggedProfiles with the given
Profileid.
21.5.3.3 TaggedProfile Interface
This interface gives access to a local representation of an
IOP::TaggedProfile.
profile_id
This attribute is the identifier for this TaggedProfile.
profile_data
This attribute is the data from the TaggedProfile. It is
normally a CDR encapsulation.
convert
Create an IOP representation of this TaggedProfile
21.5.3.4 TaggedComponent Interface
This interface gives access to a local representation of an
IOP::TaggedComponent.
component_id
This attribute is the identifier for this TaggedComponent.
component_data
This attribute is the data from the TaggedComponent. It is
normally a CDR encapsulation.
convert
Create an IOP representation of this TaggedComponent.
21.5.3.5 TaggedProfileFactory Interface
factory_id
This attribute is the identifier of profiles created by this
TaggedProfileFactory.
create
Create a TaggedProfile from the given profile_data.
21.5.3.6 TaggedComponentFactory Interface
factory_id
This attribute is the identifier of components created by this
TaggedComponentFactory.
create
Create a TaggedComponent from the given component_data.
21.5.3.7 ProfileIterator Interface
next
Returns the next TaggedProfile in the iteration. If next is called
after the last TaggedProfile has been returned, BAD_INV_ORDER will
be raised with a standard minor code of n+3.
If an IOR is modified in between calls to next, the behavior of
further calls to next is implementation dependent.
has_next
Returns true if the iteration has more elements. In other words,
returns true if next would return an element rather than throwing
an exception.
21.5.3.8 ComponentIterator Interface
next
Returns the next TaggedComponent in the iteration. If next is called
after the last TaggedComponent has been returned, BAD_INV_ORDER will
be raised with a standard minor code of n+3.
If a profile is modified in between calls to next, the behavior of
further calls to next is implementation dependent.
has_next
Returns true if the iteration has more elements. In other words,
returns true if next would return an element rather than throwing
an exception.
21.5.3.9 IIOPProfile Interface
object_key
This attribute is the Object key contained in this IIOPProfile.
profile_template
This attribute is the IIOPProfileTemplate associated with this
IIOPProfile.
21.5.3.10 IIOPProfileTemplate Interface
iiop_version
This attribute is the GIOP version of this profile. If the major
value is 1 and the minor value is 0, this profile cannot contain
any TaggedComponents.
host
This attribute is the host name string of this IIOPProfileTemplate.
port
This attribute is the port number of this IIOPProfileTemplate.
get_components
Return an iterator over the TaggedComponents within the
IIOPProfileTemplate.
get_components_by_id
Returns an iterator over the TaggedComponents with the given
ComponentId.
In current Section 21.5.3:
local interface IORInfo_3_n:IORInfo
{ ProfileIterator get_profiles (); ProfileIterator get_profiles_by_id (in IOP::ProfileId profile_id); };
21.5.3.4 get_profiles
Returns an iterator over the TaggedProfiles within the IOR.
21.5.3.5 get_profiles_by_id
Returns an iterator over the TaggedProfiles within the IOR with the
given Profileid.
Parameter Description
profile_id The IOP::ProfileId of the profiles in the iteration
to be returned.
Is:
A character literal is one or more characters enclosed in single quotes, as in ’x.’
Should be:
A character literal is one or more characters enclosed in single quotes, as in 'x'.
(note that the present version uses curly quotes and the dot is probably misplaced)
The document title in PDF metadata
is "untitled",
should be
"Common Object Request Broker Architecture (CORBA)
Specification"
It seems that the last and 4th-to-last bullets both describe the Wstring type. Thus, one should suffice.
There is lack of multiplex publisher port that would mimic functionality of multiplex receptacle. Having multiplex publisher port it would be easier to connect with dynamically created event consumers such that each consumer would have its own private communication channel with the publisher. In case of dynamically created consumers it is not possible to foresee the number of publisher ports required. For synchronous communication the elegant solution is a component with a multiplex receptacle for which we have separate communication channels.
The MIOP does not provide an analogous operation to PortableServer::POA::create_POA() for the GOA (i.e. there is no PortableGroup::GOA::create_GOA). The lack of an operation of this nature prevents the ability for an interface (i.e. servant) to subscribe to multiple (i.e. more than one) multicast group. To specify to a POA to allow multiple entries in its Active Object Map, the POAs IdUniquenessPolicy would have to be set to MULTIPLE_ID. This can only be done via the POAs create_POA operation. Since there is no GOA create_GOA operation, a GOAs IdUniquenessPolicy cannot be set to MULTIPLE_ID, which prevents a servant from being able to be subscribed to more than one multicast group. I don't know if the OMG explicitly wants to prevent this capability, thus purposely leaving it out of the MIOP specification, or if this is simply an overlooked issue.
The CORBA/e FTF slightly changed the definition of Invalid Policies to: exception InvalidPolicies
{ UShortSeq indices; }; since this avoids the use of an anonymous sequence type, consider changing it (also for consistency).
CORBA/e FTF (issue 11331): removed mention of (deprecated) function get_implementation from text. Consider making same change for consistency
The use of the '/' character to identify the object key component of a corbaloc URL is ambiguous where a protocol address also contains the character. Example: corbaloc:uiop:/tmp/uiop/xx/steve This could represent either a uiop address '/tmp/uiop' and an object key 'xx/steve/ or a uiop address '/tmp/uiop/xx' and an object key 'steve'. Suggest removing the '/' character from the list of non excaped object key characters (bottom of page 13-26)to resolve this ambiguity. The corbaloc would then become: corbaloc:uiop:/tmp/uiop/xx%27steve
There are two typo's in section A.4 on page 495.
1
SERVENT_RETENTION_POLICY_ID should be SERVANT_RETENTION_POLICY_ID
2
PortableServer::ServentRetentionPolicy should be PortableServer::ServantRetentionPolicy
In the CORBA specification, chapter 5 (Value Type
Semantics), section 5.5 (Custom Marshalling), defines
sequences of primitive types in the CORBA module,
i.e., CORBA::StringSeq et al. Some of these types are
then used by the DynamicAny and Portable Interceptor
chapters.
The presence of these typedefs in section 5.5 seems
to imply that they only need to be defined if the ORB
implements custom marshalling – a feature still
lacking in some open-source and commercial ORBs.
In my experience, having worked with multiple ORBs,
many of them do not provide the complete set of
typedefs in their "orb.idl" file. Many ORBs only
provide a limited set, usually, the set that is
exercised by the other ORB features (such as PI).
This implies that most ORBs added these typedefs
on an "as needed" basis instead of simply referring
to section 5.5.
I suggest to move these typedefs from section 5.5
into chapter 4 (ORB interface), e.g., into section
4.2 (ORB operations) to highlight that these types
should be present even if custom marshalling is not
implemented by the ORB.
Proposed resolution:
In section 5.5.2 (Marshalling Streams), cut the
type definitions, starting with AnySeq, up to and
including WStringSeq.
In section 4.2, in the IDL code fragment, at the
beginning of the CORBA module, paste the type
definitions cut above.
In the CORBA specification dated 04-03-12, the last two paragraphs on page 15-33 (section 15.4.1) describe the use of MARSHAL minor codes 7 and 8.
However, this use of these minor codes is not reflected in the table of minor codes on page A-11 (appendix A).
Furthermore, MARSHAL minor code 7 has also been assigned (at an earlier date?) to an issue resolved in the Java to IDL specification dated 03-09-04 (see page 1-50 / end of section 1.5.1.5).
This use of minor code 7 is reflected in the table in the CORBA specification.
However minor code 10, which is also specified in the same section in the Java to IDL specification, is not documented in the CORBA specification.
In summary, MARSHAL minor code 7 is double-booked, whilst minor codes 8 (used in the CORBA specification) and 10 (used by the Java to IDL specification) are not documented in the table of codes.
Proposed solution:
Change section 15.4.1 to define the use of MARSHAL minor code 9 (in addition to minor code 8), instead of MARSHAL minor code 7.
Update the table of minor codes on page A-11 with the definitions of MARSHAL minor codes 8, 9 and 10.
In section 2.10.1.1, page 22-26 (my copy is formal/04-03-01),
enumerated item 3, second bullet, the text reads "232-1 - the
maximum value for unsigned long [...]". The "32" needs to be
in superscript, i.e., to indicate "2 to the power of 32 minus
1".
The same typo exists in section 2.10.1.2, page 22-28, fourth
paragraph, second bullet (at the top of the page).
Regarding the base_interfaces attribute of the Interface Repository
(IFR) InterfaceDef and the ExtInterfaceDef interfaces, the CORBA spec
has only this to say:
"The base_interfaces attribute lists all the interfaces from which
this interface inherits."
Does that sentence mean that the base_interfaces attribute lists only
immediate base interfaces, or does it list all base interfaces,
i.e., the transitive closure of the inheritance graph (minus the
implied Object interface at the root)? I believe it is supposed to be
a list of only immediate interfaces, as one can make further calls on
the IFR to obtain more information about those bases, including
their bases.
However, both the FullInterfaceDescription and the
ExtFullInterfaceDescription structures also have a base_interfaces
member, which is specified as a sequence of repository IDs.
Unfortunately, the specification contains no description whatsoever
for this member. I argue that unlike the base_interfaces attribute
described above, this member can't list only the immediate base
interfaces.
I believe that the base_interfaces member of the
FullInterfaceDescription and the ExtFullInterfaceDescription
structures should contain the transitive closure of all base
interfaces. These structures are intended to supply full interface
descriptions, after all. Specifying the base_interfaces as I suggest
would match the operations and attributes fields of the same structs,
which are already explicitly specified to contain all operations and
attributes respectively from the transitive closure of the
inheritance graph. Note also that if base_interfaces does not contain
the transitive closure of all base interfaces, there's no way to
obtain the information from TypeCodes, since names do not appear in
TypeCodes in minimum CORBA.
I therefore propose that the third paragraph of section 10.5.24.1 of
CORBA 3.0.2 be changed from this:
"The describe_interface operation returns a FullInterfaceDescription
describing the interface, including its operations and attributes.
The operations and attributes fields of the FullInterfaceDescription
structure include descriptions of all of the operations and
attributes in the transitive closure of the inheritance graph of the
interface being described."
to add a sentence defining the base_interfaces member, like this:
"The describe_interface operation returns a FullInterfaceDescription
describing the interface, including its operations and attributes.
The operations and attributes fields of the FullInterfaceDescription
structure include descriptions of all of the operations and
attributes in the transitive closure of the inheritance graph of the
interface being described. The base_interfaces field of the
FullInterfaceDescription structure includes the repository IDs of all
the base interfaces in the transitive closure of the inheritance
graph of the interface being described, except for the repository ID
of the implied Object base interface."
Note that even if this change is made, the base_interfaces attribute
of InterfaceDef and ExtInterfaceDef can (and should) remain as
listing only immediate bases, assuming that's what the spec's
original intent was.
There was an issue 8969 (Allowing mutual recursion for IDL structures) posted sometime back on CORBA RTF (www.omg.org/issues/issue8969.txt). I am looking for a clarification in the proposed resolution, which allows for the mutual recursion between non-nested structures (CORBA 3.0 specification, section 3.11.2.3). The proposal essentially extends the definition of incompleteness of a struct/union as follows:
The original definition was:
o A struct/union is termed incomplete until its full definition is provided; that is, until the scope of the struct/union definition is closed by a terminating "}"
The introduced proposal added to the original definition:
o If a sequence member of a structure or union refers to an incomplete type, the structure or union itself remains incomplete until the member's definition is completed
Section 3.11.2.3 also says that "an incomplete type can only appear as the element type of a sequence definition".
Question 1:
Is following legal under the new scheme?
struct Foo;
typedef sequence<Foo> FooSeq;
struct Bar
{ FooSeq fs; }; // Bar remains incomplete since it is holding an incomplete sequence type
struct FooX
{ Bar b; // Is this valid with Bar marked incomplete here? };
struct Foo
{ Bar b; }; // According to the proposal, Foo and Bar are complete now
Use of Bar under FooX apparently conflicts with the condition that incomplete type can only appear in a sequence definition.
Question 2:
Also is it must that there is a mutual recursion between non-nested structures? Consider the following:
struct Foo;
typedef sequence<Foo> FooSeq;
struct Bar
{ FooSeq fs; }; // Bar remains incomplete
struct Foo
{ long a; }; // Is Bar also complete here when Foo is complete even though Foo doesn't recurse on Bar?
Is the above IDL valid under the new proposal? There is no constraint in section 3.11.2.3, which doesn't allow for this so it stands valid as per spec. Was issue 8969 also intended to make such cases valid?
I implemented CORBA functionality, in that implementation I got some exceptions. I am sending that exceptions list in the below. omniORB: ERROR – the application attempted to invoke an operation on a nil reference. terminate called after throwing an instance of 'CORBA::INV_OBJREF' Aborted (core dumped) I have some doubts on these exceptions. What is the cause for this exception? How can I solve this exception? Please clarify my doubts.
CORBA3.0.2(formal/02-12-02), chapter 7.2.1, says "The implicit object reference operations non_existent, is_a, repository_id and get_interface may be invoked using DII. No other implicit object reference operations may be invoked via DII." However, I think we should add "get_component" to this list of allowable operations. Or else we can't use some features of CCM via DII, because the implementation of get_component resides on the server side.
There are some inconsistent idl declarations in CORBA3.0.2 Chapter 9(with editorial update version) 1?page 9-10: the idl declaration of DynAnyFactory is not the same as the idl declared earlier(page 9-9). It seems that three new fuctions have been left out. 2?Page 9-5: DynUnion should have a member fuction is_set_to_default_member, which is declared on page 9-20
2. 69.8.2.8 The simple Element, page 69-538
Simple Extensions and Changes
a) Enumerations - Add an optional enumerations element to the simple
definition.
This allows a simple enumeration property to be defined. Each enumeration
label
has an associated value. The values are all of the same simple type.
Change simple element to:
<!ELEMENT simple
( description?
, value
, choices?
, enumerations?
, defaultvalue?
) >
Define new enumerations element
<!ELEMENT enumerations
( enumeration+
)>
<!ELEMENT enumeration EMPTY>
<!ATTLIST enumeration
label CDATA #REQUIRED
value CDATA #IMPLIED>
b) Short appears twice in the simple type attribute definition. Remove
second
occurrence.
<!ELEMENT simple
( description?
, value
, choices?
, defaultvalue?
) >
<!ATTLIST simple
name CDATA #IMPLIED
type ( boolean
| char |
| double |
| float |
| short – 1st occurrence |
| long |
| objref |
| octet |
| short – 2nd occurrence |
| string |
| ulong |
| ushort ) #REQUIRED > |
c) Units - add an optional units element to indicate the units of
measurement for
a simple property.
<!ELEMENT simple
( description?
, value
, choices?
, units?
, defaultvalue?
) >
<!ELEMENT units (#PCDATA)>
d) Property Kind - The properties file for a component should not be
restricted to
only initial configuration properties. A component has many different types
of
properties and when defining a component one should be able to define these
types of properties in a generic way. Add a kind element or attribute for a
property definition. A component has readonly, writeonly, and readwrite
properties. Simple properties can also be used for a component factory's
create
options parameter (home) or executable parameters/arguments. Only simple
properties can be used for executable parameters.
New simplekind element
<!ELEMENT simplekind EMPTY>
<!ATTLIST simplekind
kindtype (configure_writeonly | configure_readwrite | execparam |
query_readonly | factoryparam) "configure_readwrite">
Change simple definition to:
<!ELEMENT simple
( description?
, value
, choices?
, simplekind*
, defaultvalue?
) >
The propertykind can be an optional element or attribute for the stuct and
sequence elements.
New propertykind element
<!ELEMENT propertykind EMPTY>
<!ATTLIST propertykind
kindtype (configure_writeonly | configure_readwrite |
query_readonly | factoryparam) "configure">
Change Struct and Sequence to
<!ELEMENT struct
( description?
, ( simple
| sequence |
| struct |
| valuetype )* , propertykind? ) > <!ATTLIST struct name CDATA #IMPLIED type CDATA #REQUIRED > |
<!ELEMENT sequence
( description?
, ( simple*
| struct* |
| sequence* |
| valuetype* ) , propertykind? ) > <!ATTLIST sequence name CDATA #IMPLIED type CDATA #REQUIRED > |
Section 9.2.9 says "A reference to a DynValueCommon interface (and interfaces derived from it) exhibit the same sharing semantics as the underlying valuetype that it represents.", which defines the sharing semantics of DynAny. However, I think its precondition is that valuetype's sharing semantics can be preserved in Any. DynAny is usually used with Any, converted from or to Any. If Any can't preserve sharing semantics, there is no necessary for DynAny to keep them. Suppose we use a struct which consists of several valuetypes to store a graph. In order to ensure the correctness of an application based on DII/DSI, converting this struct to Any and then to DynAny should produce an identical graph. However, if Any can't preserve sharing semantics, this goal is impossible. Any's sharing semantics focuses on valuetype conversion, because we don't concern the concrete internal implementation of Any. It means that when we extracting valuetypes from an Any or converting an Any contains valuetypes into a DynAny, sharing semantics should be preserved. For example, different Anys contain same valuetype only produce one valuetype instance when their contents are extracted. We can implement this by the help of a global valuetype manager. To sum up, the sharing semantics of valuetype can be divided into three layers: valuetype itself, Any and DynAny. All of them constitute a complete hierarchy. Only after each layer has been implemented, we are able to ensure that applications that use the DII and DSI can correctly view and preserve the semantics of the valuetype graph. Because Any's sharing semantics is very fundamental, it is necessary for us to clarify it in the specification, though we haven't special chapter/section on Any. We can add it to Chapter 5 "Value Type Semantics". Section 5.2.4.2 only defined sharing semantics in the layer of valuetype itself. We should say something about sharing semantics in the other two layers at the end of this section.
Section 11.3.1 "The Servant IDL Type" defines the default implementations of get_interface, is_a, and non_existent. However, we should define the default implementation of "get_component" as well because this fuction is also an ORB-mediated implicit object reference operation. By default, this function returns a nil reference. When the object is a component or a facet, as other default implementations, this operation can be overridden by the servant's implementation.
CORBA 2.4 introduced forward declarations for IDL structures
and unions in support of recursive structures, deprecating the
prior practice of anonymous types.
Also allowed were sequences of forward-declared structures
("incomplete types"), which could then be used as members in
defining the structure. Currently, it is only allowed to use
incomplete types in the actual definition of the type itself.
As an example in section 3.11.2.3 demonstrates, this does
allow indirect recursion – but only if the incomplete types
are nested, as in [first example]
struct Foo;
typedef sequence<Foo> FooSeq;
struct Foo {
struct Bar
b;
};
Specifically not allowed – and this is the point of this
issue – is the seemingly more intuitive definition of
[second example]
struct Foo;
typedef sequence<Foo> FooSeq;
struct Bar
{ FooSeq fs; };
struct Foo
{ Bar b; };
Currently, the spec says that, "sequence members that are
recursive must refer to an incomplete type currently under
definition," and thus Bar is not allowed to use FooSeq as
a member.
However, the second example is, in effect, no different than
the first. In the first example, "Foo::Bar" is a well-defined
stand-alone type that can be used elsewhere (e.g., as a
structure member or operation parameter).
If a developer intends to use both structures, the second
example makes this much clearer, as it syntactically elevates
"Foo::Bar" from a mere sub-type to an "independent" structure.
Therefore, I would like to change the current wording of
section 3.11.2.3 to allow the second example. A proposed
update is below.
This issue is all the more urgent because another available
specification, the "Deployment and Configuration of
Component-based Distributed Applications," depends on it,
by using two IDL structures that mutually and indirectly
recurse, effectively using [third example]
struct Package;
typedef sequence<Package> PackageSeq;
struct Assembly;
typedef sequence<Assembly> AssemblySeq;
struct Package
{ AssemblySeq as; };
struct Assembly
{ PackageSeq ps; };
In reality, the IDL in question is a bit more complicated,
using some intermediate structures, which makes rewriting
the IDL without this mutual recursion impractical and
non-intuitive – also because both "Package" and "Assembly"
are meant to be potentially top-level, stand-alone items.
Some might argue that the IDL restriction existed before
the "Deployment" specification was adopted, and that CORBA
should not be changed just because some later spec
willingly (or rather, naively) used buggy IDL.
So let me make some more arguments in favor of my request.
First, as explained above, IDL already allows for indirect
recursion. It just requires nesting.
Second, defining structures as a "side-effect" of a member
declaration is ugly, only marginally better than anonymous
types. Allowing the type definition of a member to stand
by itself is, in my opinion, much cleaner.
Third, indirect recursion between non-nested types is no
more difficult to implement in an ORB than indirect recursion
between nested types.
In fact, some existing ORB products already have no problem
with indirect recursion, and are able to compile the IDL
from the third example, resulting in correct code. The code
works fine with Mico, TAO, JacORB and Combat, all of which
apparently neglect to implement the check that "sequence
members that are recursive must refer to an incomplete type
currently under definition."
OmniORB does issue a diagnostic, but simply removing the
check, and making another trivial change to its IDL compiler,
results in correct C++ code.
Four, the existing IDL syntax, TypeCodes, CDR marshalling
rules, and Interface Repository all allow indirect recursion
to exist. In fact, it is already possible to create the
above data types using the Interface Repository and
TypeCode interfaces – as well as to create instances
using DynamicAny, and to marshal them.
With this background, I suggest to remove the statement
that prevents indirect recursion between non-nested
structures and unions.
Proposed resolution:
In section 3.12.2.3, change paragraphs (counting each IDL
code example as a single paragraph) 10 to 12 (page 3-42)
from
If a recursive structure or union member is used,
sequence members that are recursive must refer to
an incomplete type currently under definition. For
example
struct Foo;
typedef sequence<Foo> FooSeq;
struct Bar
; // struct or union.
Compilers shall issue a diagnostic if this rule is
violated.
to
If a sequence member of a structure or union refers
to an incomplete type, the structure or union itself
remains incomplete until the member's definition is
completed. For example
struct Foo;
typedef sequence<Foo> FooSeq;
struct Bar
; // Bar itself remains incomplete
struct Foo
; // Foo and Bar are complete
Thank you for listening. Also thanks to Jeff Parsons
and Boris Kolpakov from Vanderbilt University for
researching this issue.
We, the submitters of the "Deployment" specification,
genuinely believe that indirect recursion is useful,
and its lack (and having to work around) would take
considerable value from the specification.
I am uncomfortable arguing to change another spec
to fix ours. But one spec has to change, and I believe
that indirect recursion is a useful feature that already
(unwillingly) exists in many ORBs, that it is no more
problematic to implement than the existing means of
recursion, and that the resulting data types are already
valid when obtained from the TypeCode or Interface
Repository interfaces.
Considering the conflict of available specifications,
I am tempted to flag this issue as urgent. Andrew, is
that even possible, given that there is no active Core
RTF?
Implementation Element Cardinality. Why does it make sense to have an empty
implementation or to allow multiple elements such as code, description,
humanlanguage, or to have no code? Suggested changes are to place the
correct
cardinality on the implementation elements. The suggested elements
cardinality
changes will make parsing the XML much simpler and reduce code footprint,
and the
XML more understandable.
Current Format
<!ELEMENT implementation
( description
| code |
| compiler |
| dependency |
| descriptor |
| extension |
| programminglanguage |
| humanlanguage |
| os |
| propertyfile |
| processor |
| runtime )* > <!ATTLIST implementation id ID #IMPLIED variation CDATA #IMPLIED > |
Suggested New Format for implementation
<!ELEMENT implementation
( description?
, code
, compiler?
, humanlanguage?
, programminglanguage?
, propertyfile?
, ( dependency
| descriptor |
| extension |
| os |
| processor |
| runtime |
| usescomponent )* )> <!ATTLIST implementation id ID #IMPLIED variation CDATA #IMPLIED > |
69.3.2.1 The softpkg Root Element, page 69-473
Softpkg Element Cardinality. Why does it make sense to have an empty
softpkg
file or to allow multiple elements such as title, pkgtype, description,
license, or to
have no implementations? Suggested changes are to place the correct
cardinality
on the softpkg elements to be similar to the CORBA Component and Component
Assembly Descriptor definitions. The suggested elements cardinality changes
will
make parsing the XML much simpler and reduce code footprint, and the XML
more understandable.
Current Format
<!ELEMENT softpkg
( title
| pkgtype |
| author |
| description |
| license |
| idl |
| propertyfile |
| dependency |
| descriptor |
| implementation |
| extension )* > <!ATTLIST softpkg name ID #REQUIRED version CDATA #OPTIONAL > |
Suggested New Format for Softpkg
<!ELEMENT softpkg
( title?
, author+
, description?
, propertyfile?
, license?
, pkgtype?
, implementation+
, ( idl
| dependency |
| descriptor |
| extension )* )> <!ATTLIST softpkg name ID #REQUIRED version CDATA #IMPLIED > |
7. Component Artifact - Add the capability to define a component artifact
property. For
example, a logical device component artifact could be used to specify the
capacity for
a device or the characteristic of a device. The artifacts for a component
are referenced
by a component's implementation dependency for using or deployed on
relationships.
The component artifact property could be defined in two ways: 1) a new
element
called artifact or modifying the simple definition with optional new
artifact element.
Artifacts are simple types. The action element defines the action that can
be
performed on an artifact. When a dependency references an artifact with a
specified value this is the action that can be performed against a
component's
artifact. The ID is a DCE UUID to guarantee uniqueness of the artifact
within the
system; so 2 different artifacts, which are different, are not viewed to be
the same
artifact when they are not. The action denoted as external indicates the
artifact is
managed by the component. A referenced value for an artifact would have to
be
applied against the component.
Example 1 of New Artifact Element
<!ELEMENT artifact
( description?
, simple
, action
)>
<!ATTLIST artifact
id ID #REQUIRED>
<!ELEMENT action EMPTY>
<!ATTLIST action
type ( eq | ne | gt | lt | ge | le | external ) "external">
Change properties element to
<!ELEMENT properties
( description?
, ( simple
| sequence |
| struct |
| artifact |
| valuetype )+ ) > |
Example 2 of Modified Simple Element with new Artifact element
<!ELEMENT simplekind EMPTY>
<!ATTLIST simplekind
kindtype (configure_writeonly | configure_readwrite | execparam |
query_readonly | factoryparam | artifact) "configure_readwrite">
<!ELEMENT simple
( description?
, value
, choices?
, simplekind*
, artifact?
, defaultvalue?
) >
<!ELEMENT artifact
( action
)>
<!ATTLIST artifact
id ID #REQUIRED
action ( eq | ne | gt | lt | ge | le | external ) "external">
Simple Sequence -The current definitions for sequence allow invalid
definitions to be
built but be syntactically correct. A better definition for a simple
sequence would be as
follows:
Current sequence element
<!ELEMENT sequence
( description?
, ( simple*
| struct* |
| sequence* |
| valuetype* ) ) > <!ATTLIST sequence name CDATA #IMPLIED type CDATA #REQUIRED > |
Change to
Add a new simplesequence element:
<!ELEMENT simplesequence
( description?,
, values?
, choices?
, range?
, enumerations?
, units?
)>
<!ATTLIST simplesequence
name CDATA #IMPLIED
type ( boolean | char | double | float | short | long | objref |
octet | string | ulong
| ushort ) #REQUIRED |
<!ELEMENT values
( value+
)>
Change sequence to:
<!ELEMENT sequence
( description?
, ( simplesequence
| struct* |
| sequence* |
| valuetype* ) ) > <!ATTLIST sequence name CDATA #IMPLIED type CDATA #REQUIRED > |
One does not have to keep repeating the same simple definition. This
definition
then has the added advantage where simple name attribute can now be made
mandatory.
<!ELEMENT simple
( description?
, value
, choices?
, defaultvalue?
) >
<!ATTLIST simple
name CDATA #REQUIRED
type ( boolean
| char |
| double |
| float |
| short |
| long |
| objref |
| octet |
| string |
| ulong |
| ushort ) #REQUIRED > |
This allows one
to define test properties for a component in a generic way. The Test
property is based upon simple
element.
Add new test element
<!ELEMENT test
( description
, inputvalue?
, resultvalue )>
<!ATTLIST test
name CDATA #REQUIRED>
<!ELEMENT inputvalue
( simple+ )>
<!ELEMENT resultvalue
( simple+ )>
Change properties element to:
<!ELEMENT properties
( description?
, ( simple
| sequence |
| struct |
| test |
| valuetype )+ ) > |
Choices Element - It appears multiple ranges do not make sense for a simple
definition. If so, then remove the range element from the choices element
definition
and make range an optional element for a simple.
Current definition
<!ELEMENT choices ( choice | range )+
Change to
<!ELEMENT choices ( choice )+
<!ELEMENT simple
( description?
, value
, choices?
, range?
, defaultvalue?
) >
Range Element - why is the min and max order not specified?
<!ELEMENT range (value, value) >
I understand the software logic can do a compare to determine the min and
max values, but it seems the following definition would be easier to
understand from human reader.
Change Range to
<!ELEMENT range EMPTY>
<!ATTLIST range
min CDATA #REQUIRED
max CDATA #REQUIRED>
An implementation may request a dependency on a specific component based
upon
its artifacts. Add artifactdependency to the dependency element.
Current Format
<!ELEMENT dependency
( softpkgref
| codebase | |
| fileinarchive | |
| localfile | |
| name | |
| valuetypefactory ) > <!ATTLIST dependency type CDATA #IMPLIED action (assert |
install)"assert"> |
New Format
<!ELEMENT dependency
( softpkgref
| codebase | |
| fileinarchive | |
| localfile | |
| name | |
| valuetypefactory ) , artifactdependency* > <!ATTLIST dependency type CDATA #IMPLIED action (assert |
install)"assert"> |
<!ELEMENT artifactdependency EMPTY>
<!ATTLIST artifactdependency
artifactrefid CDATA #REQUIRED
artifactvalue CDATA #REQUIRED>
Note: This concept is tied to the concept of component artifact property
issue. The
artifactrefid is a reference to a component's artifact property defined in
a
component's property file. The artifactvalue is the dependency value being
requested
or needed.
On page 11: The Normative Impact "Disable get_connections, get_all_receptacles, get_named_receptacles operations in the Receptacles interface" does not match the Document Impact: "Section 1.5.3: remove". Removal of section 1.5.3 removes the Receptacles interface in it entirety, including the description of the generic connect and disconnect operations, which are referred to by comment in the previous item. The Document Impact needs to be narrowed.
Propertyfile clarification is needed for consistent behavior.
The only statement made about propertyfile is that the implementation's
propertyfile
has precedence over the same propertyfile types at the softpkg level. Why
are
multiple property files needed at the softpkg and implementation levels? If
more than
one propertfile exist at any level, which property file has precedence in
the list? If
multiple property files exists are they merged together? Are the softpkg's
descriptor
element property files merge with the softpkg property files and which one
has
precedence? Are the implementation's descriptor property files merge with
the
implementation property files, and which one has precedence? Are
implementation
property files merge with the softpkg property files?
Change the format of author to group related authors together from a
company. One
does not need the capability to list multiple companies and web sites
together in the
author element, since there can be many authors listed in the softpkg
element. The
suggested elements cardinality changes will make parsing the XML much
simpler
and reduce code footprint, and the XML more understandable.
Current format
<!ELEMENT author
( name
| company |
| webpage )* > |
New format
<!ELEMENT author
( name*
, company?
, webpage?
)>
a) Add idl element to implementation element. Why is idl only at the
softpkg level?
This is saying that all implementations use the same IDL. This is
inconsistent with
descriptor element. An implementation can specify a descriptor, why not
idl? Cannot
an implementation use a specific IDL for its implementation?
b) Why is IDL defined in the software package descriptor instead of the
CORBA
Component descriptor?
How does the Assembly Descriptor support multiple components within an
implementation?
a) Add the optional stacksize and priority elements to code element
definition. The
stack size and priority are options parameters for an operating system's
execute()
operation. The stack size is the memory space needed by the executable and
the OS
priority for the executable. Data types for the values of these options are
unsigned
long. Priority number should be based upon industry standard such as POSIX.
Current Format
<!ELEMENT code
( ( codebase
| fileinarchive |
| link ) , entrypoint? , usage? ) > <!ATTLIST code type CDATA #IMPLIED > |
New Format for code
<!ELEMENT code
( ( codebase
| fileinarchive |
| link ) , entrypoint? , stacksize? , priority? , usage? ) > <!ATTLIST code type CDATA #IMPLIED > |
<!ELEMENT stacksize (#PCDATA)>
<!ELEMENT priority (#PCDATA)>
b) Other valid values for type attribute
Additional valid values for the type attribute are: "KernelModule",
"SharedLibrary", and "Driver".
Add license element to implementation element. Why is the license element
restricted
to the softpkg level only? This is saying all implementations have the same
license.
Cannot each implementation have its own different license? Suggest adding
license
element to implementation element.
Current Format
<!ELEMENT implementation
( description
| code |
| compiler |
| dependency |
| descriptor |
| extension |
| programminglanguage |
| humanlanguage |
| os |
| propertyfile |
| processor |
| runtime )* > <!ATTLIST implementation id ID #IMPLIED variation CDATA #IMPLIED > |
New Format
<!ELEMENT implementation
( description
| code |
| compiler |
| dependency |
| descriptor |
| extension |
| license |
| programminglanguage |
| humanlanguage |
| os |
| propertyfile |
| processor |
| runtime )* > <!ATTLIST implementation id ID #IMPLIED variation CDATA #IMPLIED > |
This issue concerns the table 4.1 "exluding support for Persistence", row 4;
there are still references to abstract storage type in the following
sections:
3.2.2 (§2), 3.2.6, 3.2.9 (point 4)
Proposed resolution:
Row 4 in the table 4.1, add in the "Document Impact" column :
Section 3.2.2, paragraph 2: remove references to abstract storage type
Section 3.2.6: remove references to abstract storage type
Section 3.2.9, point 4: remove references to abstract storage type
This issue concerns the table 4.1 "exluding support for Persistence", row 7;
there are still references to entity components in the following sections:
3.3.3.3, 4.5.1.3 (§1), 4.5.2.3 (point 3)
Proposed resolution:
Row 7 in the table 4.1, add in the "Document Impact" column :
Section 3.3.3.3: remove references to entity components
Section 4.5.1.3, paragraph 1: remove references to entity components
Section 4.5.2.3, point 3: remove references to entity components
This issue concerns the table 4.1 "exluding support for Persistence"; there
are still references to persistence in the following sections:
4.2 §1, 4.2.1 §1, 4.2.12
Proposed resolution:
Add a row in the table 4.1 with :
"Normative Exclusion" column : Exclude support for persistence
"Document Impact" column : Section 4.2, paragraph 1: remove reference to
persistence
Section 4.2.1, paragraph 1: remove reference to persistence
Section 4.2.12: remove reference to persistence
This issue concerns the table 4.1 "exluding support for Persistence", row 7;
the section 4.1.2 doesn't have to be fully removed. Only the references to
entiy container have to.
Proposed resolution:
Row 7 in the table 4.1, add in the "Document Impact" column, replace
"Section 4.1.2: remove" by "Section 4.1.2: remove reference to entity
container API types".
This issue concerns the table 4.4 "exluding support for transaction", there
are still references to the transaction feature in the following sections:
4.2 (§1), 4.2.1, 4.2.12 (basic), 4.5.1.1 (point 2), 4.5.1.4, 4.5.2.4
Proposed resolution:
Add a row in the table 4.4 with :
"Normative Exclusion" column : Exclude support for transaction
"Document Impact" column : Section 4.2, paragraph 1: remove reference to
transaction
Section 4.2.1, paragraph 1: remove reference to transaction
Section 4.2.12: remove reference to transaction
Section 4.5.1.1, point 2: remove reference to transaction
Section 4.5.1.4: remove reference to transaction
Section 4.5.2.4: remove reference to transaction
This issue concerns the table 4.5 "exluding support for security", there are
still references to the security feature in the following sections:
4.2 (§1), 4.2.1, 4.2.12 (basic), 4.5.1.1 , 4.5.1.5, 4.5.2.5
Proposed resolution:
Add a row in the table 4.5 with :
"Normative Exclusion" column : Exclude support for security
"Document Impact" column : Section 4.2, paragraph 1: remove reference to
security
Section 4.2.1, paragraph 1: remove reference to security
Section 4.2.12: remove reference to security
Section 4.5.1.1: remove reference to security
Section 4.5.1.5: remove reference to security
Section 4.5.2.5: remove reference to security
This issue concerns the table 4.1 "exluding support for Persistence", row 3;
there are still references to abstract storage homes in the following
sections:
1.7.4, 3.2.5 (§4), 3.2.6
Proposed resolution:
Row 3 in the table 4.1, add in the "Document Impact" column :
Section 1.7.4: remove references to storage home
Section 3.2.5, paragraph 4: remove references to abstract storage home
Section 3.2.6: remove references to abstract storage home
This issue concerns the table 4.1 "exluding support for Persistence", row 2;
and the table 4.3 "exluding support for segmentation", row 1: there are
still references to CIDL in the following sections:
1.5.2.1 (§1), 3.1 (§1)
Proposed resolution:
Row 2 in the table 4.1 and Row 1 in the table 4.3, add in the "Document
Impact" column :
Section 1.2.2.1, paragraph 1: remove references to CIDL
Section 3.1, paragraph 1: remove references to CIDL
This issue concerns the table 4.3 "exluding support for segmentation", row
3; there are still references to locator in the following sections:
3.3.3.5, paragraph 4 and last paragraph
Proposed resolution:
Row 3 in the table 4.3, in the "Document Impact", add:
Section 3.3.3.5, paragraph 4 and last paragraph: remove references to
locator
This issue concerns the table 4.3 "exluding support for segmentation", there
are still references to segmentation in the following sections:
: 3.2.1.6 (§1), 3.2.11 (§1), 3.2.9 (point 2), 4.2.12 (extended)
This issue concerns the table 4.8 "exluding support for home finders" there
are still references to finder operations and home finders in the following
sections:
1.7.1 (§2), 1.7.1.1, 1.7.3, 1.7.3.3, 1.7.4 (§1), 1.7.5 (heterodox), 3.3.6
(point 5), 4.3.2.1 (get_CCM_home), 4.5, 4.5.1 (point 4, last §), 4.5.1.1
(last point), 4.5.1.2
The following sections have to be removed:
1.7.3.2, 4.5.1.3, 4.5.2.3
Proposed resolution:
Add a row in the table 4.8 with :
"Normative Exclusion" column : Exclude support for home finders and finder
operations
"Document Impact" column :
Section 1.7.1, paragraph 2: remove reference to home finders and
finder operations.
Section 1.7.1.1: remove reference to home finders and finder
operations.
Section 1.7.3: remove reference to home finders and finder
operations.
Section 1.7.3.3: remove reference to home finders and finder
operations.
Section 1.7.4 paragraph 1: remove reference to home finders and
finder operations.
Section 1.7.5 (heterodox): remove reference to home finders and
finder operations.
Section 3.3.6, point 5: remove reference to home finders and finder
operations.
Section 4.3.2.1 (get_CCM_home): remove reference to home finders and
finder operations.
Section 4.5: remove reference to home finders and finder operations.
Section 4.5.1, point 4 and last paragraph: remove reference to home
finders and finder operations.
Section 4.5.1.1, last point: remove reference to home finders and
finder operations.
Section 4.5.1.2: remove reference to home finders and finder
operations.
Section 1.7.3.2: remove
Section 4.5.1.3: remove
Section 4.5.2.3: remove
This issue concerns the table 4.7 "exluding support for proxy homes", row 1;
in section 3.2.5, the last paragraph should be removed.
Proposed resolution:
Row 1 in the table 4.7, in the "Document Impact", add:
Section 3.2.5 last paragraph:remove
This issue concerns the table 4.7 "exluding support for proxy homes", row 2
and 3 are not valid
Proposed resolution:
remove the rows 2 and 3 of the table 4.7
This issue concerns the table 4.1 "exluding support for Persistence", row 1;
there are still references to primary key in the following sections:
1.7.1 (§1 & §3), 1.7.4, 1.7.5.1 (§1, §2), 1.7.5.2 (§1, §2)
Proposed resolution:
Row 1 in the table 4.1, add in the "Document Impact" column :
Section 1.7.1, paragraph 1 and 3: remove references to primary key
Section 1.7.4: remove references to primary key
Section 1.7.5.1, paragraph 1and 2: remove references to primary key
Section 1.7.5.2, paragraph 1and 2: remove references to primary key
This issue concerns the table 4.2 "exluding support introspection,
navigation, ...", row 2; there are still references to these operations in
the following sections:
1.4.3, point 3 and 4, section 1.4.3.4, paragraph 1
Proposed resolution:
Row 2 in the table 4.2, in the "Document Impact", add:
Section 1.4.3, point 3 and 4: remove references to these operations
Section 1.4.3.4, paragraph 1: remove references to these operations
This issue concerns the table 4.1 "exluding support for Persistence"; in the
"Document Impact" column, row 1, the § 3 doesn't exist in the section 1.1.4.
Proposed resolution:
Table 4.1, row 1, column "Document Impact": replace "Section 1.1.4,
paragraph 3: remove" by "Section 1.1.4, paragraph 2: remove"
This issue concerns the table 4.6 "exluding support for configurators";
there are still references to configurators in the following sections:
1.10.2 (second point), 1.10.2.1 (§2), 1.11.1 (configuration_complete)
In ptc/01-11-03, page 69-533, there is the following note
Issue The trader elements have to be reviewed to make
sure that they serve the purpose intended.
Also, consider using a property file.
XML DTD elements related to the trader service would be checked
In formal/02-06-65, page 6-54, there is the following text
Placeholder for future version.
The section 6.7.2.33 would be written.
The softpkg element only deals with deployed on and library load dependency
relationships for implementations. Component implementations may also have
specific using relationships with another component, such as a device
within the
system. This relationship can be stated at the softpkg or implementation
level.
Current Format
<!ELEMENT softpkg
( title
| pkgtype |
| author |
| description |
| license |
| idl |
| propertyfile |
| dependency |
| descriptor |
| implementation |
| extension )* > <!ATTLIST softpkg name ID #REQUIRED version CDATA #IMPLIED > |
<!ELEMENT implementation
( description
| code |
| compiler |
| dependency |
| descriptor |
| extension |
| programminglanguage |
| humanlanguage |
| os |
| propertyfile |
| processor |
| runtime )* > <!ATTLIST implementation id ID #IMPLIED variation CDATA #IMPLIED > |
New Format
<!ELEMENT softpkg
( title
| pkgtype |
| author |
| description |
| license |
| idl |
| propertyfile |
| dependency |
| descriptor |
| implementation |
| extension |
| usescomponent )* > <!ATTLIST softpkg name ID #REQUIRED version CDATA #IMPLIED > |
<!ELEMENT implementation
( description
| code |
| compiler |
| dependency |
| descriptor |
| extension |
| programminglanguage |
| humanlanguage |
| os |
| propertyfile |
| processor |
| runtime |
| usescomponent )* > <!ATTLIST implementation id ID #IMPLIED variation CDATA #IMPLIED > |
<!ELEMENT usescomponent
( artifactdependency+
)>
<!ATTLIST usescomponent
id ID #REQUIRED
type CDATA #REQUIRED>
<!ELEMENT artifactdependency EMPTY>
<!ATTLIST artifactdependency
artifactrefid CDATA #REQUIRED
artifactvalue CDATA #REQUIRED>
Note: This concept is tied to the concept of component artifact property
issue. The
artifactrefid is a reference to a component's artifact property defined in
a
component's property file. The artifactvalue is the dependency value being
requested or needed.
A component's implementation may have additional dependencies on a device's
artifacts (e.g., capacity and/or characteristics) to ensure the right type
of device is
chosen for deployment and/or the device has sufficient capacities for
deployment. To
allow for this capability add a deviceartifactdependency element to the
implementation element.
Current Format
<!ELEMENT implementation
( description
| code |
| compiler |
| dependency |
| descriptor |
| extension |
| programminglanguage |
| humanlanguage |
| os |
| propertyfile |
| processor |
| runtime )* > <!ATTLIST implementation id ID #IMPLIED variation CDATA #IMPLIED > |
New Format
<!ELEMENT implementation
( description
| code |
| compiler |
| dependency |
| descriptor |
| extension |
| programminglanguage |
| humanlanguage |
| os |
| propertyfile |
| processor |
| runtime |
| deviceartifactdependency )* > <!ATTLIST implementation id ID #IMPLIED variation CDATA #IMPLIED > |
<!ELEMENT deviceartifactdependency EMPTY>
<!ATTLIST deviceartifactdependency
artifactrefid CDATA #REQUIRED
artifactvalue CDATA #REQUIRED>
Note: This concept is tied to the concept of component artifact property
issue. The
artifactrefid is a reference to a component's artifact property defined in
a
component's property file. The artifactvalue is the dependency value being
requested or needed.
Lightweight CCM replaces CCM's Packaging and Deployment chapter
with the "Deployment and Configuration of Component-based Distributed
Applications" (D+C) specification, and thus Lightweight CCM cannot be
finalized before D+C.
I propose to defer this issue to a second FTF, to be resolved by the
availability of D+C.
This issue concerns the table 4.1 "exluding support for Persistence", row 7;
there are still references to Entity2Context in the following sections:
3.2.11 (§2)
Proposed resolution:
Row 7 in the table 4.1, in the "Document Impact", add:
Section 3.2.11, paragraph 2:remove reference to the Entity2Context
interface.
Document ptc/2001-11-03, CORBA Component Model
----------------------------------------------
62.4.1.1 The CCM2Context Interface
....
local interface CCM2Context : CCMContext
;
....
req_passivate
The req_passivate operation is used by the component to inform the container
that it wishes to be passivated when its current operation completes. To be
valid, the component must have a servant lifetime policy of component or
container. If not, the PolicyMismatch exception shall be raised.
----------------------------------------------
What happens if req_passivate() operation is not called in the scope of a
callback operation?
I think that req_passivate() can only make sense if called in the context of
a callback operation. The IllegalState exception is appropriate for this
case.
The IDL might then look like this :
void req_passivate () raises (IllegalState,PolicyMismatch);
and the following sentence might be appended to the paragraph above:
"If this operation is issued outside of the scope of a callback operation,
the IllegalState exception is returned."
This addition will ease implementation of CCM2Context objects based on
POACurrent : implementing container and component servant lifetime policies
on a POA with RETAIN servant retention policy and the other servant lifetime
policies on a POA with NON_RETAIN servant retention policy can rely entirely
on the POACurrent.
Both the CORBA spec (formal/02-06-01 page 3-61) and the CCM spec (formal/02-06-65 page 1-51) state that "A derived component type may not directly support an interface." Moreover the sentence you depicted is a contradiction with the formal/02-06-65 section 1.3.2.4 page 1-7.
Resolution:
In formal/02-06-65 page 1-51 and formal/02-06-01 page 3-61 replace the sentence
"A derived component type may not directly support an interface."
with
"If a derived component type directly supports one or more IDL interfaces, the component interface is derived from both the interface of its base component type and the supported interfaces."
Proposed resolution:
In the Adopted CORBA Components Specification (formal/02-06-65),
section 6.7.2.15, page 6-50, replace 'consumingcomponent' by
'consumesport'.
Proposed revised text:
In formal/02-06-65 page 6-50, replace
A child of consumingcomponent
by
A child of consumesport
In ptc/01-11-03, page 69-545, there is the following note
Issue The Configurator interface takes an argument of type
CCMObject and therefore cannot be used to configure component
homes. I see no reason not to widen the type to CORBA::Object
so that the Configurator can be used for objects other than
CCMObjects. The StandardConfigurator is after all a basic name
value pair configurator that simply executes calls on mutator
operations resulting from attribute declarations. J.S.E.
The Configurator interface could be updated to allow configuration
of any CORBA objects.
To maintain a consistent style and to provide a detailed
description in an XML element's first appearance, Section 6.4.5.26
and Section 6.4.5.30 should be moved under Section 6.3 and changed
to referring them back to the corresponding subsections like
Section 6.4.5.29 does.
Section 6.4.5.10 (page 6-26): one of the child elements of the
"containermanagedpersistence" element is "psstransactionpolicy" where
it should have been "psstransaction" instead (see Section 6.4.5.40
on page 6-34 and Section 7.2 on page 7-6 and 7-7).
Need to reflect the change in the PSS specification, in which the catalog is not user-defined anymore. The example and the cidl syntax (chapter 2) need to be changed too.
1. Section 6.4.5.52 (page 6-38): It says the the "storagehome" element
is a child element of "segment" where it should really say it is a
child element of "containermanagedpersistence" instead.
@@ It seems to me that generating 'local executor mapping' for supported
by a component interfaces is not needed. Even though spec doesn't say
directly that it's needed or not there are plenty of examples where it is
shown generated.
@@ According to the spec the following IDL is valid
interface I;
component C
;
home H manages C
{
};
composition session Impl
{
home executor H_Exec
;
};
@@ The following legal according to the spec IDL:
module M
{
module Components
{
struct EnterpriseComponent {};
};
component C {};
};
would result in local executor mapping that looks something like this:
module M
{
module Components
{
struct EnterpriseComponent {};
};
component C {};
};
module M
{
local interface C : Components::EnterpriseComponent {};
};
which is illegal IDL. The resolution would be to require names like
Components::EnterpriseComponent to be fully qualified e.g.
::Components::EnterpriseComponent.
The EnterpriseComponent should have a get_servant method. When creating component or facet reference of service or session component, the first step is creating the object reference and associating its PortableServer::ObjectId with servant. Currently, the container manages executor, but the EnterpriseComponent interface does not provide a mechanism to get servant. The method would be very useful as it means the container can use executor to get servant, which is not possible now.
Resolution:
Replace the following text in formal/02-06-05 on page 3-39
module Components { local interface EnterpriseComponent {}; };
with
module Components { local interface EnterpriseComponent
{ Servant get_servant() raises (CCMException); }; };
and add the operation description
get_servant
The get_servant operation returns a reference to the servant.
There is no standard way for container to intercept component state management.
By which container can implement O/R mapping and management component states.
Resolution:
Container can intercept state management by provide a storage object for executor segment.
Replace the following text in formal/02-06-05 on page 3-39
module Components
{
local interface EnterpriseComponent
{
};
};
with
module Components
{
local interface EnterpriseComponent
;
};
and add the operation description
set_persistent_object
Set context object for executors
Home executor cann't access context object. Thus some features like SMP(Self-Management Persistence) are not enabled.
Resolution:
Replace the following text in formal/02-06-05 on page 3-40
module Components {
local interface HomeExecutorBase {};
};
with
module Components {
local interface HomeExecutorBase
;
};
and add the operation description
set_context
Set context object for home executor.
This question is similar to the first one. When creating component or
facet reference of service or session component, the first step is
creating the object reference and associating its
PortableServer::ObjectId with servant. Currently, the container manages
executor, but the HomeExecutorBase interface does not provide a
mechanism to get servant. The method would be very useful as it means
the container can use executor to get servant, which is not possible now.
Resolution:
Replace the following text in formal/02-06-05 on page 3-40
module Components {
local interface HomeExecutorBase {};
};
with
module Components {
local interface HomeExecutorBase
;
};
and add the operation description
get_servant
The get_servant operation returns a reference to the servant.
When creating component or facet reference of service or session
component, the first step is creating the object reference and
associating its PortableServer::ObjectId with servant. Currently, the
container manages executor, but the EnterpriseComponent interface does
not provide a mechanism to get servant. The method would be very useful
as it means the container can use executor to get servant, which is not
possible now.
Resolution:
Replace the following text in formal/02-06-05 on page 3-39
module Components {
local interface EnterpriseComponent {};
};
with
module Components {
local interface EnterpriseComponent
;
};
and add the operation description
get_servant
The get_servant operation returns a reference to the servant.
The HomeExecutorBase should have a get_servant method. When creating component or facet reference of service or session component, the first step is creating the object reference and associating its PortableServer::ObjectId with servant. Currently, the container manages executor, but the HomeExecutorBase interface does not provide a mechanism to get servant. The method would be very useful as it means the container can use executor to get servant, which is not possible now.
Resolution:
Replace the following text in formal/02-06-05 on page 3-40
module Components { local interface HomeExecutorBase {}; };
with
module Components { local interface HomeExecutorBase
{ Servant get_servant() raises (CCMException); }; };
and add the operation description
get_servant
The get_servant operation returns a reference to the servant.
It is better to add some feature to let an assembly look like a monolithic compoment. For example, add some discriptions in CAD(compoment assembly discription) file to identify the external interface of an assembly. There exists an delegate compoment behaving like the assembly. It can navigate one external interface of an assembly to another. This delegate compoment can be created by main component server automatically according to the CAD file.
Inspired by a recent paper by Doug Schmidt and Steve Vinoski
and the resulting newsgroup discussion on comp.object.corba,
I have a feature request to introduce a better reflection
mechanism into CORBA.
At the moment, there is the CORBA::Object::get_interface()
operation to access a matching InterfaceDef entry in an
Interface Repository. Since an Interface Repository is
seldomly deployed, using this operation is pretty much
futile and will either return a nil reference or throw
an exception.
Therefore, I propose to add a new get_interface_def()
operation to the Object interface that returns a FullInter-
faceDef structure, as defined by the Interface Repository.
This structure contains all that a dynamic client (such as
the ones proposed by Schmidt&Vinoski, or software like
CorbaScript or Combat) needs to know about an interface.
A new _interface_def pseudo-operation then needs to be added
to GIOP. This could probably be done without a version change,
as no marshalling changes or new messages are involved, it's
just another operation.
On the server side, the IDL compiler would generate a suitable
implementation as part of the skeleton. This implementation
could just contain a binary representation of the FullInterface-
Description structure (just like a "precompiled" TypeCode) that
is dumped to the GIOP stream. (So that you don't need the
Interface Repository IDL around.)
Proposed resolution:
In chapter 4.3, "Object Reference Operations," add the following
operation to the Object interface:
module CORBA {
interface Object
;
};
Add the following explanation to 4.3.1, "Determining the Object
Interface"
4.3.1.2 get_interface_def
FullInterfaceDescription get_interface_def ();
The get_interface_def operation returns a data structure
describing the most derived type of the object addressed by
the reference. The FullInterfaceDescription structure includes
descriptions of all the operations and attributes in the
transitive closure of the inheritance graph of the interface
being described. See the Interface Repository chapter for the
contents of the data structure. Note that if an Interface
Repository is not available, object references contained in
this structure may be nil or inaccessible.
In chapter 15.4.2, "Request Message", update the text that
reads
In the case of CORBA::Object operations that are defined in
the CORBA Core (Section 4.2, "Object Reference Operations,"
on page 4-12) and that correspond to GIOP request messages,
the operation names are _interface, _is_a, _non_existent,
_domain_managers and _component.
to read
In the case of CORBA::Object operations that are defined in
the CORBA Core (Section 4.2, "Object Reference Operations,"
on page 4-12) and that correspond to GIOP request messages,
the operation names are _interface, _is_a, _non_existent,
_domain_managers, _component or _interface_def.
In the C++ language mapping, section 1.37.1, "Mapping of
PortableServer::Servant", add the following operation to
class ServantBase:
namespace PortableServer { // C++
class ServantBase
;
}
Update the paragraph that reads,
ServantBase provides default implementations of the
_get_interface, _is_a and _non_existent object reference
operations [...]
to read
ServantBase provides default implementations of the
_get_interface, _is_a, _non_existent and _get_interface_def
object reference operations [...]
Add a new paragraph,
For static skeletons, the default implementation of the
_get_interface_def function returns information about the
interface associated with the skeleton class. For dynamic
skeletons, the default implementation uses the
_get_interface function to determine its return value.
Other language mappings might need similar updates.
By the way, since FullInterfaceDescription is only used as
a return value, only a pointer to FullInterfaceDescription
is needed. Therefore, you don't need the full Interface
Repository interface descriptions but only a pointer to an
incomplete type.
On the client side, you only need to pull in the Interface
Repository IDL if you are actually calling _get_interface_def.
On the server side, the skeleton can do some ORB-dependent
magic to push a precompiled binary data structure into the
result.
While reviewing Victor's issue on section 1.5.3, I noticed
that a similar problem exists with respect to the Navigation
interface.
While the normative exclusion "disable get_all_facets, get_
named_facets, same_component operations in Navigation
interface" retains the generic provide_facet operation,
removing section 1.4.3.3 would remove the entire Navigation
interface.
On the other hand, the still-present section 1.4.3.4 references
the disabled operations.
Proposed resolution:
In section 10.3, in the "Document Impact" column of the second
row, replace the text
1.4.3.3: remove
with
1.4.3.3: remove these operations from the Navigation
interface. Also remove the PortDescription, FacetDescription
and FacetDescriptions types.
1.4.3.4: remove
The Session2Context interface allows developers to create an object reference from an octet sequence (object id). The the Entity2Context allows developers to create an object reference from a ComponentId. Neither the Session2Context nor the the Entity2Context allows the developer to infer the octet sequence or ComponentId that is associated with an operation invocation on a component. In other words, a developer may use a context to create multiple references that are subsequently invoked by a client. When the client invokes an operation on the reference the component code will be required to satisfy the operation invocation (either through the monolithic or the locator language mapping strategy). There is no information, however, as to which of the created references is being invoked by a client. To resolve the ambiguity the component developer must be able to use the context to provide the current octet sequence or ComponentId corresponding to the reference that is currently being invoked.
Resolution:
Replace the following text in formal/02-06-05 on page 4-37
local interface Session2Context : SessionContext, CCM2Context
{ Object create_ref (in CORBA::RepositoryId repid); Object create_ref_from_oid ( in PortableServer::ObjectIdCORBA::OctetSeq oid, in CORBA::RepositoryId repid); PortableServer::ObjectId CORBA::OctetSeq get_oid_from_ref (in Object objref) raises (IllegalState, BadComponentReference); };
with
local interface Session2Context : SessionContext, CCM2Context
{ Object create_ref (in CORBA::RepositoryId repid); Object create_ref_from_oid ( in PortableServer::ObjectIdCORBA::OctetSeq oid, in CORBA::RepositoryId repid); PortableServer::ObjectId CORBA::OctetSeq get_oid_from_ref (in Object objref) raises (IllegalState, BadComponentReference); CORBA::OctetSeq get_current_oid () raises (IllegalState); };
and add the operation description
get_current_oid
The get_current_oid operation is used by the component to extract the oid
associated with the current operation invocation. This operation must be called
within an operation invocation. If not, the IllegalState exception shall be raised.
Also, replace the following text in formal/02-06-05 on page 4-44
local interface Entity2Context : EntityContext, CCM2Context
{ ComponentId get_component_id () raises (IllegalState); ComponentId create_component_id ( in FacetId target_facet, in SegmentId target_segment, in SegmentDescrSeq seq_descrs); ComponentId create_monolithic_component_id ( in FacetId target_facet, in StateIdValue sid); Object create_ref_from_cid ( in CORBA::RepositoryId repid, in ComponentId cid); ComponentId get_cid_from_ref ( in Object objref) raises (BadComponentReference); };
with
local interface Entity2Context : EntityContext, CCM2Context
{ ComponentId get_component_id () raises (IllegalState); ComponentId create_component_id ( in FacetId target_facet, in SegmentId target_segment, in SegmentDescrSeq seq_descrs); ComponentId create_monolithic_component_id ( in FacetId target_facet, in StateIdValue sid); Object create_ref_from_cid ( in CORBA::RepositoryId repid, in ComponentId cid); ComponentId get_cid_from_ref ( in Object objref) raises (BadComponentReference); ComponentId get_current_cid () raises (IllegalState); };
and add the operation description
get_current_cid
The get_current_cid operation is used by a persistent component to retrieve the
ComponentId associated with the current operation invocation. This operation must be called
within an operation invocation. If not, the IllegalState exception shall be raised.
While reviewing Victor's issue on section 1.5.3, I noticed
that a similar problem exists with respect to the Events
interface.
While the normative exclusion "disable get_all_consumers
[...]" (8th row of section 10.3) retains the generic
get_consumer, subscribe, unsubscribe, connect_consumer
and disconnect_consumer operations, removing section 1.6.8
would remove the entire Events interface.
Proposed resolution:
In section 10.3, in the "Document Impact" column of the
8th row, replace the text
Section 1.6.8: remove
with
Section 1.6.8: remove these operations from the Events
interface. Also remove the ConsumerDescription,
EmitterDescription, SubscriberDescription and
PublisherDescription types.
-page 1-20 and page 1-21 the names of the operations get_all_receptacles get_named_receptacles are written with italic font. This seems to be a mistake.
Here is a small proposal for GIOP 1.4 with Firewall and Bidirectional. We
would get rid of all the weird nasty service contexts and make it
simplistic. The FireWall messages are only allowed before any other GIOP
messages. BiDir messages can happen at any time according to their
protocol.
What do you think? Asside from some problems I see with BiDir
offer/challenge/response correlation, it is essentially equivalent to the
solution proposed in the adopted spec.
module GIOP {
enum MsgType_1_4
;
// Firewall Traversal GIOP 1.4
struct FirewallSpec
{ boolean is_intelligent; IOP::TaggedComponentSeq endpoints; };
typedef sequence<FirewallSpec> FirewallPath;
struct FirewallPathRequestHeader
{ unsigned long host_index; FirewallPath path; };
// No body follows.
enum FirewallPathResponseStatusType
{ NO_EXCEPTION, SYSTEM_EXCEPTION };
struct FirewallPathResponseHeader
{ FirewallPathResponseStatusType status; boolean connection_complete; };
// Marshalled body immediately follows
// Bidirectional GIOP 1.4
// To keep this file uncomplicated we can introduce the
// headers and put the marshalled bodies in a separate BiDir module
// Due due some issue about the challege/response protocol for this,
// there may be a need of an offer_id to correlate them.
struct BiDirOfferHeader
{ unsigned long offer_id; };;
// Marshalled body immediately follows.
struct BiDirResponseHeader
{ unsigned long offer_id; };
// Marshalled body immediately follows.
};
GIOP Conformance and Interceptor don't play well together.
GIOP minor version conformance mandates two things.
1. That standard service contexts that are considered optional
can be ignored should the implementation not understand them.
2. That certain service contexts get processed according to the
specification of where they are defined.
This requirement works well for GIOP 1.2 where a lot of them are optional,
since (1) will apply. An implementation can claim 1.2 conformance and not
process any of them.
However, 1.3 and upcoming 1.4 will mandate the processing of them
according to their specification. In many cases, this means that some
default response may be required, which means that a GIOP 1.3, or later
engine must have a "default" response for these service contexts.
In an ORB that uses interceptors and has a generic GIOP messaging engine
there is no way for the engine to "know" when or not to process a
particular service context. It requires strict processing by the GIOP
engine, or it requires "default" interceptors to be installed to maintain
the level of conformance.
However, interceptors have no way of "declaring" which service contexts
they handle, and whether they they are overriding already installed
(default) interceptors for processing those particular service contexts.
For example, an non-transactional ORB that is GIOP 1.2 compliant must
process the Transaction Service Context by raising a
TRANSACTION_UNAVAILABLE exception, because by default the ORB is in the
OTS_NOT_CONNECTED state. It cannot be ignored to comply with GIOP 1.2 (but
by certain in implementations it ALWAYS is). A default interceptor is
needed in the ORB implementation to do this. However, for an ORB
configuration that wants to process this, there is no way for an
interceptor to "override" default processing.
The home interface could have freely defined operations or can support an
interface with such operations. A home context interface may help to implement
such operations. E.g. a home implementation needs this context interface to
determine its own object reference.
suggestion:
Add a home context interface that is similar to the component context interface.
Add a set_context operation at the HomeExecutorBase interface.
page 1-20 the description of the get_connection operation refers to a ConnectionDescription struct. In fact it is a ConnectionDescription valuetype
I believe that we send CSIv2 stuff in a GIOP Request until a corresponding
GIOP reply has been containing corresponding CSIv2 context ids is sent.
For Codeset, I think the policy is to send the service context in each
GIOP request until a corresponding GIOP Reply is received, thereby saying
that the "negotiation" is completed and excepted (otherwise an exception
will be raised.
We should probably look at the fact that multiple NSReq messages can be
sent, and there are no corresponding reply messages depending on the
service contexts.
I think that these messages should be intercepted since they are
delivering service contexts.
Although I now think I know the intent of the spec, its is ambiguous if not plain wrong with respect to valuetype fragmentation.
In particular 15.3.4.6:
Bullet 1 says:
"End tags, chunk size tags, and value tags are encoded using non-overlapping ranges
so that the unmarshaling code can tell after reading each chunk whether:
another chunk follows (positive tag).
one or multiple value types are ending at a given point in the stream (negative
tag).
a nested value follows (special large positive tag)."
Bullet 3 says:
" For the purposes of chunking, values encoded as indirections or null are treated as
non-value data."
And the pseudo-BNF says:
"(1) <value> ::= <value_tag> [ <codebase_URL> ]
[ <type_info> ] <state>
| <value_ref> (2) <value_ref> ::= <indirection_tag> <indirection> |
<null_tag> (3) <value_tag> ::= long// 0x7fffff00 <= value_tag <= 0x7fffffff (4) <type_info> ::= <rep_ids> |
<repository_id> (5) <state> ::= <octets> |
<value_data>* [ <end_tag> ] (6) <value_data> ::= <value_chunk> |
<value>" |
Now clearly the implication of bullet 1 is that an indirection or null must appear inside a chunk in a chunked encoding, otherwise you would be able to see the value 0 or -1 after a chunk and the -1 in particular could mean an end tag or an indirection. However the possible implication of bullet 3 and the BNF (note the use of "value data") is that nulls and indirections are values and thus must appear outside of chunks. Clearly the former interpretation is the correct one otherwise anarchy ensues.
So I propose that we change the 3rd bullet to say:
"For the purposes of chunking, values encoded as indirections or null are treated as
if they were not values and therefore must always appear inside a chunk when a chunked encoding is in effect."
and then change the BNF to say:
"(1) <value> ::= <concrete_value> | <value_ref>
(2) <concrete_value> ::= <value_tag> [ <codebase_URL> ]
[ <type_info> ] <state>
(3) <value_ref> ::= <indirection_tag> <indirection> | <null_tag>
(4) <value_tag> ::= long// 0x7fffff00 <= value_tag <= 0x7fffffff
(5) <type_info> ::= <rep_ids> | <repository_id>
(6) <state> ::= <octets> |<value_data>* [ <end_tag> ]
(7) <value_data> ::= <value_chunk> | <concrete_value>"
etc
We recently ran into a problem with a foreign Vendor's ORB and it appears the spec is unclear on this issue.
The problem occurs when a multi-threaded client is connecting to a server. The spec says (13.10.2.6):
"Codeset negotiation is not performed on a per-request basis, but only when a client
initially connects to a server. All text data communicated on a connection are encoded
as defined by the TCSs selected when the connection is established."
but is silent on what is supposed to happen if the client has multiple threads all trying to connect at the same time. The issue is that priority inversion can occur - either because the client sends out a request without the negotiated codeset before the one with the negotiated codeset, or because the server processes the request without the negotiated codeset before the one with the negotiated codeset (even if the latter was sent first). The problem we encountered was the latter.
There are two possible approaches to solving this:
a) Require the server to serialize connection establishment requests until the codeset (and other connection information) is negotiated. This requires that the client impose appropriate ordering on connection requests.
b) Require that the client keep sending codeset (and other connection information) until it is sure that the server has received the information (by getting a reply back). This works ok unless you are exclusively using oneways. In this instance you have to keep sending codeset information forever (somewhat costly, and very costly for codebase information).
CSIv2 (26.2.2.3) explicitly calls out (b) but I prefer (a). Do we have any guidance on what is supposed to happen?
For codesets in encapsulations we have:
15.3.3 - codesets must be "explicitly defined"
Issue 4824 - "it is an error for a Service Context to depend on information that is not contained within the encapsulation to determine the codeset used within it"
But in 13.8 there is no prescribed way of "explicitly defining" the codeset.
Please, please can we simply define that the fallbacks in 13.10.2.6 apply everywhere that the codeset is not known (whether negotiated or not) and be done with it.
Another alternative would be to add codeset parameters to the encode() and decode() functions of 13.8.
According to the IDL language it is allowed to define a facet/receptacle on a component with type of Object. The text says:
A facet is declared with the following syntax:
(120) <provides_dcl> ::= “provides” <interface_type> <identifier>
(121) <interface_type> ::= <scoped_name>
| “Object” The interface type shall be either the keyword Object, or a scoped name that denotes a previously-declared interface type which is not a component interface, ... |
In contradiction to that the Interface Repository element for a component, the ComponentDef, does only allow the creation of facets/receptacles with type of InterfaceDef. The according operations are:
// write interface
ProvidesDef create_provides (
in RepositoryId id,
in Identifier name,
in VersionSpec version,
in InterfaceDef interface_type
);
UsesDef create_uses (
in RepositoryId id,
in Identifier name,
in VersionSpec version,
in InterfaceDef interface_type,
in boolean is_multiple
);
Thus the ComponentDef can not be used to create a facet/receptacle that is of type Object, since Object is no InterfaceDef but a PrimitiveDef.
One solution would be to use IDLType instead of InterfaceDef since PrimitiveDef and InterfaceDef inherit from that interface. My proposal is to change the Interface Repository IDL in the following way.
1) replace in ComponentDef:
// write interface
ProvidesDef create_provides (
in RepositoryId id,
in Identifier name,
in VersionSpec version,
in IDLType interface_type
);
UsesDef create_uses (
in RepositoryId id,
in Identifier name,
in VersionSpec version,
in IDLType interface_type,
in boolean is_multiple
);
2) replace ProvidesDef, ProvidesDecsription, UsesDef, UsesDescription with
interface ProvidesDef : Contained
{ // read interface readonly attribute IDLType interface_type; };
struct ProvidesDescription
{ Identifier name; RepositoryId id; RepositoryId defined_in; VersionSpec version; IDLType interface_type; };
interface UsesDef : Contained
{ // read interface readonly attribute IDLType interface_type; readonly attribute boolean is_multiple; };
struct UsesDescription
{ Identifier name; RepositoryId id; RepositoryId defined_in; VersionSpec version; IDLType interface_type; boolean is_multiple; };
Suppose you are sending a request (GIOP 1.2 or 1.3) and the request will
be fragmented into two segments. The first segment is a Request message
that has the GIOP Header and part of the Request Header. The second
segment is a Fragment message that has a GIOP Header, a Fragment Header,
and the body is the remainder of the Request Header and the Request Body.
Section 15.4.2.2 of CORBA 3.0 states that the Request Body (in a Request
Message) should always be aligned on an 8 octet boundary.
My question is, in the above scenario, where the Request Body begins in
the Fragment message, should the Request Body be aligned on an 8 octet
boundary or not? I have not found anything in the specification that
explicitly says what to do.
I found some minor editorial issues in the spec (referring to the document 02-06-65).
Add field AP-ID (String, Optional) to the message. ME4 should refer to this field for its value. Add field VCID (String, Optional) to the message. ME4 should refer to this field for its value.
Are required for CCSDS packets only, and optional otherwise.
All fields in the UML Model classes are shown as Private. This would make sense if these blocks were really supposed to be classes, but in their usage in C2MS, these are handled as structures with all fields accessible.
Since we are already going to change every UML diagram in C2MS 1.1, we should consider if it would be good to change these all to Public.
See the attachment for a comparison between fields. Private fields are marked with '-', while private fields (like DATA shown as an example) are marked with '+'.
C2MS 1.0 defines MESSAGE-CLASS as an optional field (in the C2MS Header, "Generic field for missions to classify their message set to aid message disposition.").
A principal user of C2MS reclassifies MESSAGE-CLASS as a required field with a finite set of defined enum-like values.
In order to help align this user with C2MS, the C2MS MESSAGE-CLASS field should become required. Alternatively, C2MS should define a way for a consumer of the C2MS definitions to require what is to C2MS an optional field with defined values.
The Archive Message Retrieval Request Message and related Archive Message Retrieval Response Message should be considered for deprecation.
These are useful messages in an engineering environment when all messages and their corresponding storage method allows unfettered access to all consumers regardless of authentication/authorization, but in a real-world operational environment, this construct is much too uncontrolled.
For example, the Archive Message Request allows, and suggests, sending a SQL statement or script expression in the REQ-STRING field, which the service provider would execute on behalf of the requestor, creating an exploitable cyber attack opportunity for malicious software.
Even if the REQ-STRING were removed and the request only allowed for PROD-TYPE/PROD-SUBTYPE (the other way to request the archive), this would allow for all messages that ever flowed in the environment to be forwarded to a single requestor. In an unsecured system, that might make sense, but it is not appropriate in any system that closely controls who is allowed to send/receive any given message.
One goal for consistency (and ease of implementation and use of said implementation) is to have all subject elements also be fields in the message. Adding DESTINATION-COMPONENT late in the adoption process of C2MS was a step in this direction, but DESTINATION-NODE and DESTINATION-FACILITY are needed also. See page 82 for example for CFG messages.
(Note: this applies to all 5 C2CX messages - CFG, CNTL, DEV, HB, and RES)
Add field AP-ID (String, Optional) to the message. ME4 should refer to this field for its value.
Subject not able to be fully created from Message fields in all cases.
Add fields DESTINATION-NODE (String, Optional) and DESTINATION-FACILITY (String, Optional) to the messages. ME3 and ME4 should refer to those two fields for their values, respectively.
Add field AP-ID (String, Required) to the message. ME4 should refer to this field for its value. If field AP-ID is added as OPTIONAL, then ME4 should also be changed to OPTIONAL.
Set the association multiplicity for required fields to '1' and optional fields to '0..1'
The LOG message is nice to cover a certain scope of messages needing to be utilize by developers using the specification, however the ProductMessage again and again finds itself utilized instead of the LOG message because of the structure the LOG message has versus the ProductMessage for making things like status or event messages.
Because of this, I had looked at the ALMAS specification from Navy and the CAP (Common Alerting Protocol) from OMG to come up with an Alert Notification and Alert Ack message that would be greatly helpful in making a solid Header for alert and status messages that could be different in scope than typical LOG messages.
I have these messages defined in GMSEC/COMPATC2, and would need to attach it for you to see the details. Thank you
It would greatly aid readability of the specification if the tables listing the message contents by field separated the required fields from the optional fields. By doing this, the UML and descriptive tables would be in alignment.
This is true throughout, but for one pretty clear example, see section 8.6.1.3. The UML (figure 8-13) (page 101) and the table (table 8-69) are hard to read together when looking at both.
In this case, there are two blocks in the UML diagram that contain fields: one block is "Required Fields" and the other "Optional Fields". The table, simply shows fields. When reading down the fields in the table, the listed fields come from the two different UML blocks in the following order:
1-Required
2-Optional
3-Required
4-Optional
5-Optional
6-Required
7-Required
8-Optional
9-Optional
10-Required
It would be much more clear to have all the fields in the table be listed in the same order as the UML diagram, with Required first, followed by Optional, along with a column specifying required or optional. Alternatively, there could be two tables: one for required fields in the same order as the "Required Fields" block of UML, and a second table with all the optional fields in the same order as the "Optional Fields" block of UML.
As mentioned above, this is one example, but this disconnect between the UML and the Fields table is true throughout the document.
The ".... Message Header Notes" tables can be confusing. For example, table 8-8. It should be made clear that the fields listed in those tables are from the Message Header definition, but the values apply only for that specific message. A small wording change would go a long way to helping, especially for newer users.
For most of the message types in C2MS, this convention is followed. The exceptions are:
-Archive Message Retrieval Request
-Archive Message Retrieval Response
These were likely left this way because they already have "Message" in the name, though with a different meaning. Archive Message Retrieval Request Message does sound redundant. Perhaps renaming to any of the following would help:
Not using "Archive Message" in the title is a bit confusing because there is Archive data that is not simply archived messages, see "Archive Mnemonic Value Request Message"
Note that when originally entered, this issue listed all the following... but in 1.1, the only messages not ending in "Message" are the Archive request/responses.
-Archive Message Retrieval Request
-Archive Message Retrieval Response
-Telemetry Message for CCSDS Packet
-Telemetry Message for CCSDS Frame
-Telemetry Message for TDM Frame
I do not expect this can be addressed by the FTF. Suggest vote to defer to a future revision.
The messages for mnemonic access do not appear to include a request/response for "setting" the value of a parameter (mnemonic) from an application participating using C2MS. This capability is used for ground and other types of non-telemetered parameters (mnemonics).
if I do not write it down, I will forget.
I believe the distinction between "Header String" and "String" types is to enforce compliance with Subject Element format (UPPERCASE Alphanumeric, "-" and "_" as only valid values). The description of "Header string" in Table 8-1, Field Type Definitions, indicates that this type is used for "subject name elements".
It's a bit confusing to call this a "Header String", because not all Strings in the Header are Header Strings, and some fields are Header String type even though they are not in the Header (Some examples: USER, SUBCLASS, REFERENCE-ID, and OCCURRENCE-TYPE in Log, CNTL-KEYWORD in Control Message).
In all cases, the fields that are Header String type are intended to be used as subject elements.
One side note, that would need to be fixed, either way is that the actual type listed in Table 8-1, Field Type Definitions, lists the type in two places as "Header string" (lowercase s on string), where everywhere else in the document and in UML model figures, it is listed as "Header String".
Numerous field tables in C2MS allow reusing the same REQUEST-ID for a request to provide a "replacement". For example, MVAL REQ Message says in the Fields table (Table 8-99) under REQUEST-ID:
"ID to identify the request message - if different request messages have the same value, the request is a replacement; else, it is a new request"
In all cases, this is the only explanatory text of what is meant by "replacement". This is pretty ambiguous about expected result. So, for example,
There's no description of semantics regarding what is being replaced.
A related issue is STOP request, specifying non-symmetrical MVALs, and what to do in that situation.
In C2MS 1.0, in every instance of sending a REQUEST-ID as part of a request, the Notes for the field states the identical, "ID to identify the request message – if different request messages have the same value, the request is a replacement; else, it is a new request." However this copy-paste doesn't always make sense.
Re-use of a REQUEST-ID only makes sense if the request leaves some process continuing to fulfill data streaming. Only two request messages have a start/stop concept. Therefore, this resolution assumes no other messages have a use case for 'replacement' and removes the confusing extra text.
Additionally, the concept of 'replacement' is not needed in the two cases where start/stop actions are present... just stop the old one and start a new one. Using 'replacement' can lead to confusion.
The way the UML is shown for each message, each C2MS message inherits the Message Header type. This isn't really semantically correct.
Consider the diagram from section 8.6.3.3 (although this is true throughout all message specifications), which is included as Attachment 1. Organized this way, this UML means that Telemetry TDM Frame Message IS A Message Header, rather than that it contains a Message Header.
THere are two options for making this a little more clear:
Option A is that Instead, they should be subclasses of something called "C2MS Message" that itself contains a Message Header, as shown in Attachment 2, in which Telemetry TDM Frame Message IS A C2MS Message, and all C2MS Messages contain a Message Header.
Option B is to use composition where each message contains a message header. This is as shown in Attachment 3.
It's not a major point, but would increase readability and have better optics.
After discussion, Option B seems like the right choice.
This issue is related to C2MS11-30, which is about the table immediately prior to every message UML diagram. The UML diagrams, for example figure 8-3, seem to indicate that "MESSAGE-TYPE" and "MESSAGE-SUBTYPE" are fields in the individual message when they are actually in the Message Header.
The NODE and USER-NAME fields are tracking fields supplied by the implementation (API). They should just be whatever strings are returned by the local o/s rather than forcing them to be of type Header String (upper alphanumeric, "-", "_").
In the Message Header (pages 41-45), add the fields DESTINATION_NODE and DESTINATION_FACILITY as Optional with type of Header String. This enhances the routing/subscribing options currently available for the DESTINATION_COMPONENT field.
There is no “need Echo” in the EGS REQ CMD Message. At present, all we can say is that based on MUS configuration, EGS CMDECHO may be generated.
I propose using a new Boolean CMD-ECHO field in Command Request Message to indicate if an ECHO should be sent at any configured point along the ground chain as the command is transmitted.
This would be an Optional field, defaulting to FALSE.
Add fields that allow encryption of content sections of C2MS messages as well as message signatures or message authentication codes. This would not assume or provide any particular mechanism to encrypt/sign, but would allow for tracking of these fields to aid usage.
The benefit of doing this is to allow the Mission to determine levels of security and secure componentry, but to use the message definition as a way to track this information.
Note that currently, GMSEC provides a level of encryption/signing, but my thought is that it would be preferred to allow the mission to manage this outside the transport layer. Providing encryption/signing FIELDS in the message definition allows for this decouplling.
I've got some specific ideas about how to do this, which I can share, but just want to capture the need here.
Tracking fields do not specifically belong in a C2MS Message. Rather, there should be a message envelope that contains these fields for the purpose of delivering a contained C2MS message. Recommended here, is to define a C2MB Sister spec that encompasses the 'how' of sending C2MS messages. This is the logical place for managing tracking fields in a "Message Envelope".
This is clear when considering tracking fields, MW-INFO and CONNECTION-ID, which are message-bus handling constructs and have no meaning in C2MS itself.
Typo in the diagram only for Archive Message Retrieval Response calls the Header fields it uses MSG-TYPE and MSG-SUBTYPE. They should be MESSAGE-TYPE and MESSAGE-SUBTYPE, respectively. See page 64, figure 8-5.
In the Control Message, the field SPECIAL_INFO is Binary type in the UML diagram (Figure 8-9), but is described as "For application use. Any additional information can be provided here." (Table 8-48).
Because C2MS has no definition or understanding of the binary format, it is probably better if the type be changed to "String", so that opaque data is not transmitted around the system where only the producer and consumer can understand what it is. Log messages, for example, would not be able to record, in any meaningful way, what was sent in the control message.
Change the CNTL-STRING field in the Control Message from optional to required. That field is the reason for the message. This also will be consistent with Directive Message, where DIRECTIVE-STRING is required. See Figure 8-9.
The field CNTL-KEYWORD in the Control Message is supposed to contain the keyword extracted from the field CNTL-STRING. It should not be fixed. So, remove the value from the diagram. Figure 8-9. This is a Model change.
See C2MS11-47.
This is just a documentation clarification. Header Strings are the type used for building message subjects. It's invalid for a message subject element to be null. So, Header Strings need to be at least one character.
In Log, Directive Request, and Simple Service Request, there is a USER field for use by communicating applications. This field should be moved to the Message Header, so that any message can utilize this field.
Note: in the Log Message this field is used in the subject, so is defined as a Header String. In the Directive and Simple Service messages, it is not used in the subject so is defined as a string.
Note 2: There is another field in the Message Header called USER-NAME; this is a tracking Field, so is reserved for use by the implementation and is the account/user name that started the application.
The intent of tracking fields is to reserve them for use by the implementation. So, to be complete, these fields should be added to the specification. If any of these fields were to be inadvertently added to the messages by an application, the implementation (GMSEC API) could potentially overwrite their values.
Some services may depend on other services to satisfy a request. Create a MEP that discusses and shows how this could work.
I’d like to recommend a review of the Replay Telemetry Data Request Message compared to the Archive Mnemonic Value Request Message. These two messages should be nearly identical in form, but appear to have grown up in neighborhoods on opposite sides of the tracks.
Some base behaviors are different between the two. Many fields exist in one request message but not the other. In one case, the same field exists in both request messages, but has a different meaning. The response paradigm is different between the two message sets.
This issue is to harmonize the two message sets.
Throughout this discussion, I’ll use the following abbreviations:
Sections below describe elements of the two that are dissimilar:
For TLM, the Message is called Replay Telemetry Data Request Message (RTDRM). For the MVAL it is Archive Mnemonic Value Request Message (AMVRM). Since both have the concept (implemented differently) of replay, but the AMVRM has a way to receive the data as an output file, I think that “Archive” is more meaningful. In fact the descriptive text under the RTDRM, refers to the “Telemetry Archive component”. So, I’d suggest renaming the RTDRM to Archive Telemetry Data Request Message to match better with Archive Mnemonic Value Request Message.
Replay Telemetry Data Message set includes a long description of how to use the “replay” service provider as a way to get real-time, or even future TLM messages (Section 8.7). There is no analog in Archive Mnemonic Value Messages.
I recommend we don’t include that discussion in the Archive Mnemonic Value Messages. It seems odd to have “replay” messages for something that isn’t replay. I believe the same intent can be achieved by simply requesting a “replay” whose end-date-time is in the future, and indicate that the archive service will continue to send out TLM, as long as it is put in the archive during that window. That is logically similar, without trying to fake out the system, because the data would still originate from the archive.
The STREAM-MODE of the RTDRM (sec 8.7.1.3) can be RT or RPY, to accommodate the intent of separating real-time from replay. I don’t’ think this is needed. If we assume that we only replay data that is in the archive, whether it is arriving into the archive now or in the future, this is logically the same and wouldn’t require special handling in the message definition.
Section 8.7.1 indicates that the two fields PLAYBACK-RATIO and DATA-RATE (described in sec 8.7.1.3) only apply if the STREAM-MODE is RT. However, having to specify STREAM-MODE as RT or RPY doesn’t seen necessary. These values could easily be applied to RPY: this would mean that the playback rate would be some ratio of the timing of the original TLM (play back at the same rate it was originally received, or some ratio related to it) or play it back at a certain data rate, from the archive. The distinction makes it awkward and I don’t think it’s necessary. The AMVRM uses PLAYBACK-RATIO and DATA-RATE with exactly these meanings, without any indicator of STREAM-MODE.
I’m confused about what is meant by the fields of the RTDRM in Section 8.7.1.3 for files. There is a NUM-OF-FILES and a FILE.n.NAME-PATTERN, with very limited description of how this is to be used. The only clue is in Section 8.7.1, where there is indication that this only applies to a “real-time data stream”. I’m not sure how the requester is to know the names of files in the archive and why this would only apply to RT. Probably should be removed, unless we have a specific use-case for it.
STREAM-MODE (described in sec 8.7.1.3) exists in RTDRM, but not in AMVRM at all. This would be useful in AMVRM, because STREAM-MODE can indicate SIM or TEST. RT and RPY are not needed, as described above.
In addition to retrieving MVAL Data Messages as a stream, the AMVRM also has the concept of requesting the entire data set in a single message. In fact, this can either be in the payload of the single message or the data can be placed in a file at a specified URI. The RTDRM does not have this concept at all, and all retrieved TLM must be in a set of streamed messages. I like this capability of the AMVRM and recommend that it be added to the RTDRM.
One oddity in this concept is that in the AMVRM (sec 8.9.1.3), if the RESPONSE-VIA-MSG is set to RESP.AMVAL, then it can be delivered in the single message or at a URI. However, the selection is controlled by two Boolean fields: DELIVER-VIA-REFERENCE (URI) and DELIVER-VIA-INCLUDE (message payload). It’s odd that these are separate Booleans, because there is no description of what would happen if they are both set to ‘0’ or if they are both set to ‘1’. I can surmise that setting both to ‘0’ would be an error and setting both to ‘1’ would mean to deliver the data set in both the single data message and also at the URI, but it’s hard to imagine the usefulness of doing so. I’d recommend we drop DELIVER-VIA-INCLUDE and just use the DELIVER-VIA-REFERENCE to mean that the data is to be EITHER in a URI OR in the data message.
The RTDRM has an ACTION field to control flow (start, stop, etc). There is no analogue in AMVRM, but there probably should be.
The AMVRM has a PDB-VERSION field. This field does not exist in RTDRM. To me this seems way down in the weeds, and was probably an add-on for a special one-off case somewhere along the line. Is it necessary? If not it should be removed. If so, it should be added to RTDRM as well.
RTDRM can specify a particular orbit. This field does not exist in AMVRM.
RTDRM, as discussed earlier, has fields for the source files for TLM. This concept doesn’t exist for AMVRM. Unless we can come up with a specific use case for this (along with a better description of the fields in the RTDRM), I’d be in favor or dropping it from RTDRM. Otherwise, it should probably be added to AMVRM for consistency.
Both RTDRM and AMVRM have a FORMAT field. They are used for different purposes. I’d recommend calling the one in RTDRM TLM_FORMAT and the one in AMVRM something like FILE_FORMAT since that corresponds to their use.
RTDRM has VCID and APID fields. The AMVRM does not. Yet, the MVALs originated from the same TLM stream, so these seem applicable to AMVRM. Needs discussion. Note that both request messages have COLLECTION-POINT with identical meaning, so the origination of TLM and MVALs are tied in that way.
In the RTDRM, asking to retrieve TLM messages results in identical TLM messages to when these messages came in, real-time. The only exception is in the STREAM-MODE of that message type, which is set to RT for original messages, or RPY for messages coming out of the archive. This is a useful construct.
However, for AMVRM, the original real-time messages have one format, defined in section 8.8.3.3 and a different format for messages retrieved from the archive, described in section 8.9.3.3.
It seems logical to use either one pattern or the other. I prefer the pattern used by TLM, where the original message format reappears, but with a designator that it is a RPY message.
In the current version of the model, there is no descriptive documentation within the model itself. This could be easily added from the non-normative specification and would aid engineering teams who use the model.
Justin Boss:
A username or alternate security credential should be able to be provided with all C2MS requests (and possibly should be required)?
Systems should not automatically trust remote clients and therefore a credential should be required with all messages. This would allow components to authorize and audit requests on a per-user/connection level.
In the current specification, RAW-VALUE is limited to a 32-bit integer and EU-VALUE is limited to 64-bit float (i.e., double). These data types should be changed to allow larger data types to be represented (at a minimum, 64-bit integer should be supported throughout). (From Justin Boss)
I do not expect this can be addressed by the FTF. Suggest vote to defer to a future revision.
For a complete implementation of C2MS on the systems I use, we need some kind of Procedure Script Execution set of messages. These would include being able to launch procedures, monitor them, show progress, etc. This could be a topic of some significant discussion and is entirely new scope. The closest analogue I have so far found is the Activity Tracking stuff in the CCSDS Mission Operations Common Services.
if I do not write it down, I will forget.
Requesting data, such as telemetry, via pub/sub requires knowing the publisher's server name. There should be a way to request data without this being already known. This could potentially be solved by a registry concept, as in C2MS11-1, but this particular issue proposes adding a service-matching capability wherein the requester is asking for a subscription to some data and the request results in linking the subscription to a service that provides that data.
This to be consistent with the XTCE Specification. Moreover Mnemonic isn't accurate as the very definition of mnemonic is a shorthand "code" for the actual parameter name.
Recommend close/deferring this issue, but believe it's important to capture our rationale as the community will ask why the inconsistency between SDTF specifications.
C2MS should offer a mechanism for clients and/or servers to be able to check validity of a subscription.
(C2CX Heartbeat) Section 8.5.4
(Archive Mnemonic Value Request) Section 8.9.1
The AMVR message has a field called FORMAT that is of type String, but there is no enumeration of possible formats. This could be handled by requestor and supplier agree on a format.
FORMAT is used to define the file format of the return data.
Discoverability of data is still a major concern due to the lack of a registry.
I do not expect this can be addressed by the FTF. Suggest vote to defer to a future revision.
It seems that there is a consensus that we need database data dictionary informational messages. It seems to be in work. Capturing the item here.
if I do not write it down, I will forget.
The IDL to C++11 language mapping got extended to allow setting the union value and discriminator in one operation, see https://issues.omg.org/issues/CPP1114-14. This could be done in this language mapping also, but keep the discriminator, that keeps it backwards compatible
p16 7.3.6 cont'd
[19] context ConsumesDe inv:
component.contents->includesAll (consumess)
-> context ConsumesDef
p18 7.3.6 cont'd
[36] Contraints [33], [34], and [35] apply recursively to valuetype members that are valuetypes.
-> Constraints
p18 7.3.6 cont'd
[33, 34, 35, 36] isAcceptableKeyType (type)
isAcceptableKeyType (valueType : ValueDef) : Boolean
{ valueType.contents.forAll
( c | c.oclIsTypeOf(ValuefMemberDef) implies c.OclAsType (ValueMemberDef).isPublicMember)
-> c.oclIsTypeOf(ValueMemberDef)
-> c.oclAsType (ValueMemberDef)
(using lowercase "o" at c.oclAsType)
p19 top
else result = home.key endi f }
-> endif }
p32 paragraph below Figure 7.16, last sentence
The Binding metaclass has two attributes: “name” (the name of the Binding) and “CCMQoS
metamodel: Bindingmandatory” (if “true,” then the QoS property is bound in any case).
-> Change “CCMQoS metamodel: Bindingmandatory” to “mandatory”
p44 CORBAUnion example
enum Contents { INTEGER_CL; FLOAT_CL; DOUBLE_CL; COMPLEX_CL; STRUCTURED_CL; };
The delimiter for enum values is a comma; the value list should be:
INTEGER_CL,
FLOAT_CL,
DOUBLE_CL,
COMPLEX_CL,
STRUCTURED_CL
};
p45 Figure 8.9 - Union example (a)
-> Remove class «CORBAUnion» "Reading", it is redundant to fig. 8.10
p45 Figure 8.10 - Union example (b)
┌──────────────────────────────────────────────────────────┐
│ «CORBAUnion» │
│ Reading │
├──────────────────────────────────────────────────────────┤
│ «CORBASwitch» discriminator: Contents │
│ «CORBACase» a_long: long {lable=INTEGER_CL} │
│ «CORBACase» a_double: double {lable=FLOAT_CL, DOUBLE_CL} │
│ «CORBACase» an_any: any {lable=default} │
└──────────────────────────────────────────────────────────┘
"lable" -> "label"
p45 CORBAStruct example
struct Problem { string expression; Fraction result; Boolean correctness;
-> boolean correctness;
(lowercase "b" at "boolean")
p49 CORBAArray list 1st bullet 4th sentence
- Named by a typedef declaration arrays are represented by the UML DataType [...]
[...] The value of the “tag „index” is a list of integers separated by comma [...]
-> The value of the tag “index”
p62 Constraints
[43-4] Contraints [43-1], [43-2], and [43-3] apply recursively to [...]
-> Constraints
p62 Constraints
[43-1, 43-2, 43-3, 43-4] isAcceptableKeyType(type)
isAcceptableKeyType (valueType : ValueDef) : boolean
{ valueType.contents.forAll (c | c.oclIsTypeOf(ValuefMemberDef) implies
c.OclAsType(ValueMemberDef).isPublicMember) and
-> c.oclIsTypeOf(ValueMemberDef)
-> c.oclAsType(ValueMemberDef)
(with lowercase "o" at c.oclAsType)
p63 8.2.3 Example
typedef enum PhilosopherState {
Use of `typedef` in this context is archaic. Omit `typedef`:
enum PhilosopherState
{
p63 8.2.3 Example
eventtype StatusInfo { public string name; public PhilosopherState state; public long secondesSinceLastMeal;
-> secondsSinceLastMeal
p66 Figure 8.25 bottom left
┌─────────────────────┐
│ <<enumeration>> │
│ ComponentCategory │
├─────────────────────┤
│ ▱ session │
│ ▱ entity │
│ ▱ process │
│ ▱ sevice │
│ ▱ extension │
└─────────────────────┘
-> service
p71 paragraph before 8.4.2
[...] All these files are represented using a UML Artifact with stereotypes
<<CORBAAComponentFile>>, <<CORBAAIDLFile>>, <<CORBAAContainedFile>>, and <<CORBAADependentFile>>.
-> CORBAComponentFile , CORBAIDLFile , CORBAContainedFile , CORBADependentFile
p71 Table 8.4 rightmost column header Const-raints
-> Constraints
p82 Class2Interface
Class2Interface (cl, itf)
FORALL UML1Class cl WHERE c.stereotype = "CORBAInterface" || "CORBAHome“
CREATE UML2Interface itf
SETTING itf.stereotype = cl.stereotype, itf.name = cl.name, itf.attribute = cl.attribute, itf.operation = cl.opertaion,
-> cl.operation
p86 9.2.1 example, cont'd
interface RetrieveRadarData { /* callculates the List of radar contacts visible for a given position of a Radar */
-> calculates
Page 47 beneath Figure 8.13 contains:
The extended UML metamodel contains an abstract stereotype <<CORBATemplate>>, which is a generalization of <<CORBAString>>, <<CORBAWstring>>, and <<CORBASequence>> stereotypes. All <<CORBATemplate>> elements have a tag “bound” that indicates the maximum size of the element.
Page 48 CORBASequence contains:
Sequences are represented in the Profile by two means:
- Named by a typedef declaration sequences are represented by the UML DataType with the stereotype <<CORBASequence>>. Sequence members are represented by an attribute of the DataType, which always has the name “members” (profile keyword), members type is represented by the type of the “members”-attribute and the max size is represented by the multiplicity of the “members”-attribute.
[...]
Thus there appear to be two mechanisms for specifying the string/sequence bound,
I propose following clarification:
When defining a bounded string or a bounded sequence, * If the bound value is a plain number, the multiplicity upper bound of the "members" attribute shall be used for carrying the bound number. * If the bound is a symbolic constant then the stereotype tag "bound" shall be used. It shall carry the fully qualified name of the IDL constant.
Reason:
Use of attribute multiplicity for the symbolic constant representing the string/sequence bound is problematic.
Most UML tools do not support such symbols in the UML attribute multiplicity expression.
Consider the following IDL:
module config {
const short max_size = 8;
};
module types {
typedef string<config::max_size> name_t;
typedef sequence<boolean, config::max_size> bool_seq_t;
};
Here, in both cases the multiplicity of the members attribute shall not be used. Instead, the stereotype tag bound shall contain "config::max_size"
for the typedef-datatypes.
The IDL example on page 41 above Figure 8.6 is:
module Y
{
constant short S = 3;
interface X
{
constant long L = S + 20;
};
};
The keyword for IDL constants is const, i.e.
const short S = 3;
[...]
const long L = S + 20;
CORBASequence uses multiplicity at the member members to define the sequence upper bound.
The most frequent case of CORBAArray is the single dimensional array.
Proposal: Permit using the members multiplicity for this common case in a similar way as for bounded sequence.
When using this alternative way of modeling:
Modeling of multi dimensional arrays is not in affected by this proposal.
According to the IDL 4.2 grammar, the bound number of bounded sequence / bounded string and fixed array size is a
positive_int_const which resolves to const_expr.
In the examples for bounded sequence an array, the specification only shows literal constants used for the sizes.
It is not defined how to use expressions, such as a reference to an IDL const declaration, as the size.
At the least, it should be required to model a UML Dependency association from the CORBASequence / CORBAArray type to the const declaration.
The specification omits support for the IDL native declaration.
Section 8.1.2 defines stereotypes CORBAAnonymousSequence and CORBAAnonymousArray for mapping sequence/array attributes of struct/union/valuetype/interface without a dedicated typedef.
However, an equivalent CORBAAnonymousString stereotype is not defined.
Thus it is not obvious how to map e.g.
struct struct_with_anon_bounded_str {
string<32> anon_bounded_str;
};
union union_with_anon_bounded_str switch (boolean) {
case TRUE:
string<32> anon_bounded_str;
};
valuetype valuetype_with_anon_bounded_str {
public string<32> anon_bounded_str;
};
interface interface_with_anon_bounded_str {
attribute string<32> anon_bounded_str;
};
Event Listeners without a defined Event (User or Timer) are concrete elements and can be added to CMMN models.
However, the execution semantics are not clear.
Is the listener immediately triggered since there is nothing to wait for? Or does it wait indefinitely since there is nothing to wait for?
[the former would be preferable]
There are modeling styles that would use empty Event Listeners and it should be made clear if this is valid for execution.
The UML Profile for CORBA and CCM on page 47 states:
The extended UML metamodel contains an abstract stereotype <<CORBATemplate>>, which is a generalization of <<CORBAString>>, <<CORBAWstring>>, and <<CORBASequence>> stereotypes.
The part about «CORBAString» and «CORBAWstring» inheriting from «CORBATemplate» does not fit with figure 8.7 on page 42 which shows that those stereotypes inherit from «CORBABounded».
According to the class diagram, the sentence should be:
The extended UML metamodel contains an abstract stereotype <<CORBATemplate>>, which is a generalization of <<CORBAArray>> and <<CORBASequence>> stereotypes.
In spec text and meta-model the Diagram Interchange attributes fillColor, strokeColor and fontColor are spelled with a lowercase first letter. However, in the XML Schemal they are spelled with an uppercase first letter: FillColor, StrokeColor and FontColor.
Proposal:
Adjust spelling in text and MM, because XSD is already implemented and in use.
All initial transitions (create transitions) contain "create" trigger/event. It's illegal according to UML specification (State Machines).
We could use "/create" instead to specify what kind of behavior is executing while transiting from initial node to the first state e.g. Active.
I was wondering why the stage autocomplete doesn't take into account the event listeners. At some point in time, it might be possible that a stage has no active children, but an event is still waiting for something. So in this case, I would expect that the stage doesn't autocomplete until the event has happened.
Is there a reason why this is implemented otherwise?
Figure 7.4 'CMMN Shape' shows an attribute isExpanded instead of isCollapsed, which is described in spec text, tables and XML schema.
Proposal:
In Figure 7.4 on page 85 (PDF 101) replace attribute isExpanded with isCollapsed.
The condition expression of ManualActivationRules, RequiredRules and RepetitionRules is optional as shown in Figure 5.13 (PlanItemControl class diagram) on page 50 (PDF 66).
Therefore, CMMN has to define default behaviors for two cases:
The following sentences seem to define a default for case 2 in Table 5.49 (PlanItemControl attributes and model associations) on page 50 (PDF 66):
"A ManualActivationRule comprises of an Expression that MUST evaluate to boolean. If no ManualActivationRule is specified, then the default is considered “true.”"
However, instead of defining the behavior for a missing condition expression (case 2), it talks about the marker itself and thereby accidentally makes all tasks and stages manual by default if they don't have the manual activation marker (case 1).
This is completely contradicting the meaning of the manual activation marker: It would mean that a task can only be activated automatically, if it has a ManualActivationRule with a condition set to "false". By having a ManualActivationRule that task also gets the manual activation marker although it is activated automatically. On the other hand a task that has no ManualActivationRule would not get the manual activation marker although it is activated manually.
Similar sentences are correct for case 1, but fail to define a default for case 2 in Table 5.49 (PlanItemControl attributes and model associations) on page 51 (PDF 67):
"A RequiredRule comprises of an Expression that MUST evaluate to boolean. If no RequiredRule is specified, the default is “false.”"
"A RepetitionRule comprises of an Expression that MUST evaluate to boolean. If no RepetitionRule object is specified, the default is “false.”"
Furthermore, there is a cardinality mismatch between Tables 5.50, 5.51 & 5.52 and MM/XSD for conditions of ManualActivationRules, RequiredRules and RepetitionRules
This issue has been confirmed by people that worked in the CMMN specification. In particular: Mike Marin (IBM), Denis Gagné (Trisotech), Henk de Man (VDMbee), Ralf Mueller (Oracle) and Falko Menge (Camunda). They expect to see this issue fixed in the next CMMN version. In the meantime, they encourage all implementers and users of CMMN to read "false" instead of "true" in the description of attribute manualActivationRule in CMMN 1.1 Table 5.49 (PlanItemControl attributes and model associations), because the current specification text can lead to misinterpretations. Correct behavior is described in the following image:
replace the following sentence:
"If no ManualActivationRule is specified, then the default is considered “true.”"
with:
"If no ManualActivationRule is specified, then the default is considered “false.”"
Replace "Expression[1]" with "Expression[0..1]".
Add the following sentence to the description of the attribute condition:
"If no Expression is specified, then the default is considered “true.”"
Replace "Expression[1]" with "Expression[0..1]".
Add the following sentence to the description of the attribute condition:
"If no Expression is specified, then the default is considered “true.”"
Replace "Expression[1]" with "Expression[0..1]".
Add the following sentence to the description of the attribute condition:
"If no Expression is specified, then the default is considered “true.”"
Meta Model and XML schema use condition with lowercase c whereas Table 5.51 uses an uppercase C.
Proposal:
In Table 5.51 - RequiredRule attributes on page 52 (PDF 68) replace "Condition" with "condition".
It may be useful to be able to define the Performer for task of type Process and Case
When visually modeling it is often desired to have a planItem react to multiple standard events (e.g. when a certain caseFileItem is created or update or addchild or removechild etc. do this).
Presently it is required to visually depict multiple copies of the caseFileItem with a separate onPart for each of the Standard events we want to react to because onPart can only have one standard event.
It is proposed to allow onPart to have multiple standard events defined all of them in a disjontion (e.g. created OR addchild OR removechild or etc.)
The wsdl files provided at http://www.omg.org/spec/CTS2/1.1/ are not correct. #
We tried to generate java services with wsdl2java using these wsdl and xsd files but got errors due to faulty namespace settings and incorrect fault settings in the methods.
Where can we obtain the correct wsdl files to implement CTS2 specification conform soap services?
here's a thing that has been bugging me for a while: the description of the
semantics of the iterators in some of the CORBA Services seems to be unclear
and inconsistent. They falls into two categories:
Semantics A: returned value is relevant for the next invocation
PropertyService says:
The next_one() operation returns TRUE if an item exists at the current
position in the iterator ... A return of FALSE signifies no more items in
the iterator.
Interoperable Naming Service says:
The next_one() operation returns the next binding. It returns TRUE if it is
returning a binding, FALSE if there are no more bindings to retrieve. If
next_one() returns FALSE, the returned Binding is indeterminate.
(the intention behind this is actually different, see below, as Michi
Henning pointed out to me)
The Trader Service (e.g. OfferIdIterator) says:
The next_n() operations returns TRUE if there are further offer identifiers
to be extracted from the iterator. It returns FALSE if there are no
further offer identifiers to be extracted.
(this is also clear, even though I don't think this is the rigth design).
Semantics B: returned value is relevant for the past invocation:
The Collection Service:
retrieve_element_set_to_next() returns TRUE if an element has been
retrieved.
(This is really clear)
In case A, a client always has to check whether s/he got something useful in
the out parameter (since a FALSE return only says something about the
subsequent call); this is not very elegant. In case B, a client always has to
spend a fruitles round-trip to the server to know when the iteration is
finished. This is IMO a better solution, and should preferably be adhered to
by any OMG standard.
SQL-99 is superseded by SQL:2003 (see comment on 3), which is mainly the same except that BIT and BIT VARYING data types are no longer included.
Proposed Solution: None proposed by source
The precise semantics of the use of the CWM Expression class (and
its subclasses) as the type of attributes of CWM classes is not clearly
delineated (as discussed at the 7/12/01 CWM RTF meeting in Danvers, MA).
Review the semantics of existing attribute types that are also CWM classes
and correct them as needed.
Support for XMI for XML Schemas The above will probably be adopted at the September 2001 meeting. CWM should consider generating XML Schemas, in both XMI 1.x and XMI 2.0 flavors. Note that there is a new directory and naming structure that allows a single metamodel to have many physical artifacts at different versions with clarity of access.
A sequence is a relational database object that allows the automatic generation of values. Sequences are ideally suited to the task of generating unique key values. Applications can use sequences to avoid possible concurrency and performance problems resulting from the generation of a unique counter outside the database. Currently, the CWM Relational package does not provide a representation for sequence. It should be added.
This should be part of BusinessInformation: it is not at all specific to WarehouseOperations since one could request changes to database schemas, transformations or pretty much anything.
'isActive' would be better than 'completed' for ChangeRequest, and would observe the convention of using 'is' for booleans. Moreover it should be a derived nonchangeable attribute to avoid inconsistency with 'status'.
The reference from ChangeRequest to ModelElement should be 0..* since the request might be to create something new that cannot yet be referred to!
The following are considered essential for most ChangeRequests: 1) two multivalued optional references to ResponsibleParty to indicate: a) raiser b) actionee 2) optional single-valued integer attribute 'priority' (larger value = more important), constrained to be non-negative. 3) optional single-valued string attributes 'raisersIdentifier' and 'identifier' (representing an id allocated by the raiser and that used internally by the warehouse management system). 4) optional multivalued string attribute 'history' to describe events in managing the request. 5) optional string attribute 'resolution' to decribe what actually happened (e.g. how the modelElements were changed, why the request was rejected etc).
"...and several examples are provided in Volume 2, Extensions, of the CWM Specification." This document is not referenced in either Clause 3 or the References Annex, and its role in this specification is not defined.
Modern object-oriented programming languages such as Java and C#
support the notion of exceptions as first class objects. However, the CWM
Object resource package does not provide support for exceptions. Although
exceptions might be added to extension packages specifically designed for
each language that needs them, such an approach would not promote
interchange of exceptions between data warehouse components written in
different languages. This problem will become particularly accute for .NET
languages in which particular exceptions are defined by language independent
components (such as the .NET CLR libraries) and can be returned to
application components written in any of a group of languages. Suggested
approaches to resolving this difficulty might include (1) adding exceptions
to the CWM Behavioral package or (2) creating an Object package and placing
the new exception classes in it.
This issue is to capture what has been stated in Chapter 12 of the CWM specification. The XML package should be revised and extended to represent XML Schema metadata as soon as XML Schema is adopted by W3Cas a recommendation (which happened in 5/01).
Nature of Problem:
A normative reference for OCL is required, because it is used in Clause 8 (and elsewhere)
Proposed Solution: None proposed by source
These tables gives data types from X/Open CLI SQL, which is not referenced in either Clause 3 or the References Annex but should not be used because they should be data types defined by SQL and the mappings defined by the current version (4) of JDBC.
Proposed Solution: None proposed by source
This annex should not be described as Normative, since all normative references should be in Clause 3. Some of the non-normative reference should be normative and be moved to Clause 3. All references should be to current specifications.
Proposed Solution: None proposed by source
The record and multidimensional arrays are aggregate datatypes and the common features of 11404 aggregates should be supported.
Proposed Solution:
Add features for 11404 aggregates.
CWM_1.0.dtd is missing the following element:
<!ELEMENT CWM:ModelElement.taggedValue (CWM:TaggedValue)*>
This element should be a child element of CWM:ModelElement and all elements
that correspond to subclasses of ModelElement.
Without this element, CWM_1.0.dtd does not conform to the CWM 1.0
Metamodel. According to the metamodel, any ModelElement (or its subclass)
can own TaggedValue through the TaggedElement aggregation.
Metamodels described in the CWM specification employ certain
modeling techniques and packaging styles in preference to others. However,
the current text of the specification does not clearly delineate, or provide
a rationale for, which modeling techniques and packaging styles are
preferred and which are not. Because stylistic consistency is an important
part of promoting both understandability and implementability, text should
be added to the specification (possibly in Chapter 6) delineating preferred
modeling techniques and packaging. Such documentation will provide guidance
to submitters of enhancements to existing CWM metamodels and of new or
replacement metamodel packges.
This should be part of Foundation (probably Expressions or BusinessInformation): it is not at all specific to WarehouseOperations since one could apply measures to tables (for expected volumes), transformations etc.
Measurement should have an optional reference to an Expression to define how the value has/should be calculated.
An SQLParameter has no attribute. It should have some of the Column attribute: length, precision, scale and isNullable at minimum. This is valid for all the RDBMS.
The multidimensional arrays should support the notion of APL arrays, including rank and shape attributes.
Proposed Solution:
Add support for flat and nested N-dimensional arrays (not just arrays nested as arrays).
Expression and their subtypes (BooleanExpression, etc.) were changed from Data Types (in the CWM Adapted Specification) to Classes in CWM 1.0. As a result, it caused design inconsistency in CWM. For example, ExpressionNode inherits from Element. This was designed originally based on the fact that Expression was a Data Type and could not be subclassed. It should now inherit from Expression, which can be subclassed. The CWM RTF should review and revise all such inconsistencies caused by changing Expression, Multiplicity, etc. from Data Types to Classes.
It's not at all clear how one links from a WarehouseProcess or TransformationExecution to the physical information that it is applied to (e.g. if the same information is replicated across a number of physical locations which is actually used as the source of a datawarehouse load?).
At the Process level there is the opportunity for some sophistication (e.g. to list a number of physical sources/destinations in priority order); at the execution level one should record the actual instance used.
Similarly one may want to specify and record which DeployedComponent(s) should be used to carry out the transformation.
Nature of Problem:
It is inappropriate to use the name Procedure for referring to both procedures and functions (see 10.3.9). SQL uses the term routine for this purpose.
Proposed Solution: None proposed by source
Sections 8.3 and 8.3.1.7 justify ResponsibleParty inheriting from Namespace in that it can be used for "capturing organizational structures or similar relationships". This is not only quite obscure but is inadequate for even very simple and common Warehouse-oriented situations - due to the strict composition semantics of Namespace. In particular it does not allow a single person to belong to more than one Position/Team, nor does it allow the representation of matrix/management relationships which are very common. Moreover it does not allow the separation of two very different concepts: packaging of models and organizational relationships.
An example 'test' scenario is of 2 support teams: one for Corp Database A, another for Corp Database B. Both will always have the same Manager (regardless of who is currently filling that position) and make use the same Performance Specialist, John Wicks.
It is proposed that CWM adopt a simple but specific Organization Structure metamodel (no more than 5 classes such as Unit, Position, Person) that also aims for consistency with OMG's recently adopted Organizational Structure Facility.
Anyway, I think that there is a little error on the figure 6-6 chapter 6.2.4 of the v1.1 (wich is the figure 6, page 212 in the PDF, chapter 9.2.4 on the "old" document) : the Person has a "salary Column" instead of a "name column".
The description of referencingColumn implies that only a 'column' (i.e. an attribute) of a structured type can be of a type REF, whereas any column of a table can be so.
Proposed Solution: None proposed by source
SQL-92 and SQL-99 should not be used since they are no longer valid, and should NOT be described as ANSI documents
Proposed Solution: None proposed by source
The attribute XMLNamespace (also shown in Figure 13.1) is defined as a string, but it is an XML concept described by a specification separate from the referenced [XML], and quite distinct from the CWM concept of Namespace, and so should be referenced and described appropriately.
Proposed Solution: None proposed by source
Support for XMI 1.2 XMI 1.2 will probably be adopted at the September 2001 meeting. CWM should consider generating XMI 1.2 DTDs. Note that there is a new directory and naming structure that allows a single metamodel to have many physical artifacts at different versions with clarity of access.
This applies to CWM 1.1 (and also CWM 1.0).
Sun MDR user Vincent Lombart spotted that he was getting the same
association exported twice, which I tracked down to the following problem in
the metamodel.
There should be no explicit association between ClassifierMap and
TransformationMap: the diagram in the CWM spec just documents the fact that
the inherited ownedElement association is used to link these classes.
The CWM XMI file is produced by the Unisys Rose integration which explicitly
ignores such associations (signalled by '/' on the association ends - normal
derived associations have '/' on the association name). This is used in
several places e.g. in Relational model to show that Column and ColumnSet
are linked using the owner-feature association.
However in the ClassifierMap case there are also corresponding references
explicitly defined as pseudo-attributes on Classifier and TransformationMap
which has caused the references erroneously to be generated into the XMI
file.
On further investigation, the following inherited associations have
superfluous references:
XML:ElementType <-> XML:Schema
XML:ElementType <-> XML:Attribute
Transformation:TransformationMap <-> Transformation:ClasifierMap
Transformation:TransformationActivity <-> TransformationStep (in this case
the references are called 'step' and 'activity')
BusinessNomenclature:Taxonomy <-> Concept
BusinessNomenclature:Glossary <-> Term
BusinessNomenclature:BusinessDomain <-> Taxonomy (in this case one
reference is called just 'domain')
Proposed resolution:
Delete the above references/pseudo-attributes (with stereotype of
<<reference>> though this is hidden on the diagram).
In the SoftwareDeployment package, consider changing
DeployedComponent from being a subclass of Core::Package to being as
subclasss of Core::Subsystem. This change preserves the package nature of
DeployedComponents and, at the same time, adds the ability of
DeployedComponents to have features (because Core::Subsystem is a subclass
of Core::Classifier, as well as Core::Package).
The Data Mining metamodel contains a sub-metamodel on classification/categorization, which is generic and which can be useful outside of data mining but in a data warehousing/business intelligence context. Following the tradition of CWM's design emphasis on modularity and reuse, this sub-metamodel should be made a separate package from the Data Mining package.
The full set of 11404 aggregates (record, array, set, bag, sequence, etc.) should be supported.
Proposed Solution:
Support the full set of 11404 aggregates.
Nature of Problem:
The figure does not enclose emp_t in parenthesis (..) as shown correctly in the associated text.
Proposed Solution: None proposed by source
This normative annex appears to conflict with the intellectual property rights of ISO standards, and does not take account of the ISO requirement that all potential patents should be declared.
Proposed Solution: None proposed by source
Support for MOF 1.4 MOF 1.4 will probably be adopted at the September 2001 meeting. CWM should consider using MOF 1.4 for its metamodel, which will bring particular benefits in the area of DataTypes. Note that there is a new OMG directory and naming structure that allows a single metamodel to have many physical artifacts at different versions with clarity of access.
This is an issue deferred from the CWM FTF. The metamodel for DTD should be reviewed, and revised if necessary, to make sure that it fully represents DTD information and that it is consistent with the new metamodel for XML Schema.
CWM vol. 2 3.1 says "The concepts and ideas implicit in the definition of the COBOL language's DATA DIVISION were one of the earliest (if not the first) formalizations of the ubiquitous record model. A COBOL program contains much more than just record descriptions. However, because neither CWM nor UML attempt to describe programming languages directly, only the DATA DIVISION is described here. The model presented here is compliant to the COBOL 85 language standard [COBOL]."
UML Profile for EAI 14.1 says "The goal of this COBOL model is to capture the information that would be found in the Data Division." .
Both define COBOL Data Division metamodels with different levels of detail. We only need one COBOL Data Division metamodel.
Nature of Problem:
The referenced [SQL], the basis of this clause, is given as SQL:1999, which is no longer valid because it has been superseded by SQL:2003
Proposed Solution: None proposed by source
Nature of Problem:
This should make it clear that indexing is not part of SQL, and the use of SQLIndex in Figure 10.10 is entirely inappropriate.
Proposed Solution: None proposed by source
"XML Schema is an ongoing activity in the W3C. As future standards are adopted by the W3C on XML Schema, this package will be revised and extended accordingly." This document is not referenced in either Clause 3 or the References Annex, and the claimed revision has clearly not occurred.
Proposed Solution: None proposed by source
This annex should not be described as Normative, since it does not provide any requirement on the application of this standard as well as being incomplete and missing or being in conflict with the terminology of other normative references, such as SQL. The reference to RM-ODP is inappropriate, not being one of the listed sources.
Proposed Solution: None proposed by source
The 'predefined' values for SoftwareDeployment::SoftwareSystem.type (and subtype) should be formally defined as Constants in the metamodel. Similarly for WarehouseOperation::ChangeRequest.status and WarehouseOperation::Measure.type (there are probably others).
By using the inherited ElementOwnership association to link SOftwareSystem and Component, this would seem to prevent the same component being reused in many systems. Though an Import association is depicted in Figure 8-7-1, nothing is said in the text about its semantics in this context: typically this would be used just for definitions/types ("extending the namespace" according to the description in the Core model) and not something that would need to be physically deployed as part of the SoftwareSystem.
Proposed resolution: Introduce a new many-to-many shared aggregation to link SoftwareSystem and Component.
CWM uses a subset of UML for practical reasons. It also delegates the modeling of Object Oriented resources to that subset. However the way this is currently done makes it unnecessarily hard to take a model exported from a UML tool and import it as the model of an OO resource in CWM.
CWM should provide support e.g. via metamodel and/or documented best practice (e.g. use of XMI namespaces) for this.
I think a parameter must have a multiplicity, because otherwise there can be never ever overgiven/returned an array to/from an behavioralfeature. I think this is not correct, i think maybe this is right for input parameters, but i think for output or return parameters there must be an multiplicity to model an behavioralfeauture correct.
Nature of Problem:
"A structured type is defined in terms of columns" - the SQL standard defines a structured type in terms of attributes and it is totally confusing to define it in terms of columns. A column can exist only within tables and can have constraints, which are not allowed for attributes of a structured type.
Proposed Solution: None proposed by source
The attributes length, precision and scale should not be present, because they are exactly the same as those for the related sqlSimpleType. What should be included are the methods that can be defined for distinct types.
Proposed Solution: None proposed by source
The supplierDependency reference is missing from ModelElement, which existed in the CWM Adapted Specification.This change makes the model illogical and unbalanced. Dependency is always defined between two ModelElements (a client and a supplier). Its definition involves two associations and four association ends. Either the supplierDependency reference should be put back (which makes a more flexible model) or the client reference on Dependency should also be removed (which makes a more restrictive model, but at least it is logical and balanced). (This is a revised write-up for issue #3398.)
This is an issue deferred from the CWM FTF. Description, Document and ResponsibleParty should be made subtypes of Comment, allowing use of the corresponding reference on ModelElement.
Nature of Problem:
A normative reference for ISO/IEC 9075:2003 Database language SQL is required, because it is the basis of Clause 10 (any previous edition has been superseded)
Proposed Solution: None proposed by source
Table: this currently reference a Table. However, most RDBMS support "instead of" triggers which can be applied to views. Table should be replaced by a reference to a NamedColumnSet
An essential feature of SQL structured types is that they have methods, whose properties should be recorded
Proposed Solution: None proposed by source
Usage experience with the CWM 1.0 Transformation package has
uncovered several situations in which the package may fail to permit
definition of transformations that fully capture the intent of implementors.
Such problems have appeared in several unrelated modeling venues and have
led some implementors to seek alternative means for describing
transformations. The existing transformation package should be reviewed by
the RTF and changed as needed to improve its ability to represent the
breadth of transformation semantics found in practical usage scenarios. As
part of this effort, the RTF should consider incorporating the existing
TypeMapping package into an evolved Transformation package – TypeMappings
are, after all, really just lightweight transformations.
The planned XML Schema package proposed for inclusion in CWM 1.1
should be cognizant of and wherever possible, equivalent to, the XML Schema
model planned for the inclusion in the XMI specification. Within reason,
corresponding XML Schema-specific class in the two specifications show share
the same names, attributes, and relationships to other classes.
XML metamodel should be based on W3C XML Information Set. W3C has a standard called XML Information Set http://www.w3.org/TR/xml-infoset/ (at Candidate Recommendation status) "This specification defines an abstract data set called the XML Information Set (Infoset). Its purpose is to provide a consistent set of definitions for use in other specifications that need to refer to the information in a well-formed XML document"
In effect it defines an information model for XML with the following Information Items (the equivalent of classes in CWM): Document, Element, Attribute, Processing Instruction, Unexpanded Entity Reference, Character, Comment, Document Type Declaration, Unparsed Entity,Notation, Namespace. It would seem that since this is what W3C says should be modeled for XML documents then this should be the basis of the CWM XML model (the content part as opposed to the Schema part), or at least CWM should specify how it maps to this Information Set.
The expressions metamodel should have the kind of syntax associated the expression (e.g., is the expression C, APL, ksh, or something else, which all have significantly different parsing and syntax.
Proposed Solution:
Add the syntax type to the metamodel.
This annex is inappropriate in this standard, but if it remains it must be non-normative because it does not provide any requirement on the application of this standard.
Proposed Solution: None proposed by source
There is no requirement that the value "name" attribute of ModelElement correspond to the identifier (i.e., the string) of the model element.
Proposed Solution:
Add requirement that the "name" actually corresponds to the identifier of the model element.
The 11404 datatype generator features should be included via the expressions metamodel capability.
Proposed Solution:
Add datatype generators
These are gained from having tried to use the model in real situations.
a) Add new attribute Contact.applicability: String (0..1), to allow a fuller description of when that
contact should be used (e.g. "After hours or weekend emergencies only: when completion of a
time-critical run is threatened").
b) the associations between COntact and its constituent parts (Telephhone etc) should be shown as aggregations (not compositions) for clarity. This will have no effect on generated code/DTDs.
c) split the phoneNumber attribute into its constituent parts. This is because the actual number to ring is dependent on context), and there may be uses where automatic dialing is required (e.g. for fax/pager access to contacts). [It is assumed that the calling progam knows what country/area it is dialing from). The proposed replacement attributes (all optional and of type String) are: countryCode inCountryAreaPrefix (e.g. for UK it would be "0" - one dials +44 1202 449419 outside UK but 01202 449419 inside UK) areaCode corePhoneNumber.
This is an issue deferred from the CWM FTF. Per recommendation from the Architecture Board, all OCL sections should be reviewed to ensure that they are complete
Nature of Problem:
SQL should not be considered as an abbreviation for Structured Query Language
Proposed Solution: None proposed by source
Nature of Problem:
"Apart from this Foreword, the text of this International Standard is identical with that for the OMG specification for CWM 1.1 (formal/03-03-02)."
While true of the current document this cannot hold if changes are made to respond to NB comments.
Proposed Solution: None proposed by source
The specification does not identify the exact versions of MOF, UML and XMI that it refers to. Even if more than one version is applicable this needs to be made clear.
The question is about 99-07-41.pdf, as far as I know the latest C++ mapping specification. "1.41.5 Any Class" prescribes "Boolean operator>>=(const Any&, const char*&);" for unbounded strings, and "1.16.3 Extraction from any" says that unbounded strings are extracted by value. This seems to be contradictory: I seem to remember that const char* cannot be delete'd, though I don't find it in ISO/IEC 14882:1998(E). But, regardless of anything imposed by C++, the current mapping precludes a safe technique like (safe as in exception-proof): >> String_var theString; if(!(theAny>>=theString.out()))
{ ... }<< I therefore propose that the mapping be changed to "Boolean operator>>=(const Any&, char*&);". This seems to work all right on my implementation (RayORB), for gcc 3.2 (MS VC++ 6.0 doesn't seem to care one way or the other, but I suppose that is wrong, although I'm not entirely sure).
The datatype attributes don't incorporate the features of 11404 datatype (properties, characterizing operations, value spaces). There is no way to record this kind of standard datatyping information in CWM in a standard way.
Proposed Solution:
Add these features to the metamodel. Describe, in a standard way, how datatype characterizing operations would be recorded.
Provide in the body of a CWM interchange document, a means for
identifying the precise CWM definition to which the interchange document
conforms. Something similar to the way the XML documents identify the URI
of the XML definition they conform to would do nicely. Such a mechanism in
effect creates a name space within which the contents of the CWM interchange
document can be evaluated. Useful side effects of having such a namespace
include: (1) the definition of CWM extension packages without the present
need that they be accompanied by the CWM definition itself, (2) a framework
in which Universally Unique Identifiers (UUIDs) can be defined for each CWM
object. Several requests for CWM UUIDs have already been received
informally.
The attribute typeNumber is not an SQL concept, and since it is described as being assigned by the owning DBMS this makes it totally useless for any exchange between different DBMSs.
Proposed Solution: None proposed by source
Summary: The idl spec for the CollectionFactories interface in Chapter 17 of Corba Common Object Services document and the spec for the same interface in The CORBAservices OMG IDLText File(last updated Feb, 1998) do not match. The doocument (17-73) describes a method
Summary: A number of interface changes suggested for the Collection specification.
Summary: What should be done for remove/replace/retrieve_element_set_to_next if the element cannot be deleted/replaced/retrieved?
Summary: If I want to use the DII to send out multiple simultaneous requests, I don"t see a practical way to associate any client specific context that is C++ compliant to those requests.
Summary: Calls for removing and retrieving the first and last element can throw an EmptyCollection exception. Why can"t the calls remove_elements_at_position and retrieve_element_at_position throw such an exception?
Summary: Positions are numbered. When I remove 1 element, what happens with the indices?Do the portions of the indices of the elements located after the removed element decrement one?
Summary: If a invocation of do_on on a certain element returns false, does the iteration have to stop, leaving some of the objects undone?Or do I continue until the end and then return false?
Summary: The side effects states that iterators that point to removed elements go in-between, and others keep theit state. If all elements are removed I doubt that some iterators can keep their state. I would set all iterators the invalid state...comments?
Summary: Page 17-23:"If the collection supports unique elements or keys...". If I already have a different element with the same key, do I return and add false?
Summary: There is a confusing/conflicting situation in 2 parts of the document. Page 17-12 Map/SortedMap states that you can insert an object with 2 different keys (nicknames). The first note on page 17-122 states that if both key and element equality are defined, element and equality must imply key equality.
Summary: Same case for RACollectionFactories) on page 17-74, 17-75 as in issue 763
Summary: The operation "create (ParameterList parameters) raises (ParameterInvalid)" is not mentioned in the CollectionFactories interface, while it is fully explained on page 17-73
Summary: Page 17-89, description of the retrieve_element_set_to_next operation in the Iterator interface: The signature of this operation is missing the second parameter "more".
in UML Profile for CORBA, where it describes the UML notation examples for mapping of CORBA sequences/arrays...there is some significant confusion on my part with respect to the notation examples given. See Figure 3-27 for an example. In this figure the class stereotyped as <<CORBAAnonymousSequence>> has a composition association with a class stereotyped as <<CORBAPrimitive>>. The latter class has the following text appearing in the name compartment: "CORBA::short". I am bewildered at how the type can be represented in the name compartment of the class. I am trying to use a tool to auto-generate IDL from UML, and have no way to represent this, and I am unsure if this is even valid as per the UML specification. Is this legal, or is necessary to have an attribute that is of type CORBA::short in the attribute compartment?
Chapter 9 should be clearly marked as non-normative. Noted during smsc review. Thus, formal document number not available
P. 51 . The CORBAUses stereotype has a property "multiple" of type PrimitiveKind P. 53 . The CORBAUses stereotype has a property "isMultiple" of type boolean. This looks like a naming and type inconsistency between diagram and tabular representation of the stereotype. If this is the case and isMultiple is really typed boolean, PrimitiveKind becomes useless (I did not find any other use of PrimitiveKind in the profile). If not (I mean PrimitiveKind is the wanted type), it may be better to type the "multiple" property with the "CORBAPrimitive" stereotype instead of creating and using an enumeration like PrimitiveKind.
Litteral of the enumeration PrimitiveKind are prefixed with "CORBA" or "Corba", instead of "CORBA" (upper case) for all litterals
For the stereotype designating IDL "typedef", the UML Profile for CORBA
v1.0 (02-04-01) uses the capitalization "CORBATypedef".
The UML Profile for CORBA and CCM v1.0 (08-04-07) sometimes uses the
same capitalization but also uses the capitalization "CORBATypeDef"
(notice the capital "D".)
For compatibility with the UML Profile for CORBA, I suggest replacing
all occurrences of "CORBATypeDef" by "CORBATypedef".
The definition of the stereotype CORBAPrimaryKey makes too strong restrictions. The CORBA Component Model defines a primary key as an ordinary valuetype, which is derived from Components::PrimaryKeyBase. Using the stereotype PrimaryKey would prevent me from using this valuetype in other parts of my application as a plain valuetype (e.g operation parameter). Suggestion: Remove stereotyp CORBAPrimaryKey. Use stereotype CORBAValueDef instead and refomulate the constraints accordingly. (e.g. inheritance)
Facet and Receptacles (ports) are specified as an UML association, but their names are specified as role names of the association end of the referenced interface. It means, the component refers directly to the external interface it’s confusing and less intuitiv. Suggestion: Facet and Receptacle names are the names of the associations, describing ports.
The (IDL) definition of the example is not correct. The valuetyp for the key is not allowed to be abstract and it must have at least one public member. Furthermore, this key needs to be derived from Components::PrimaryKeyBase. The picture of the UML model should also be completely shown (i.e. including the member of the primary key). Suggestion: Modify example (IDL and picture)
Event ports are specified as an UML association, but their names are specified as role names of the association end of the referenced event. It means, the component refers directly to the external event it’s confusing. Suggestion: Event port (such as Facet and Receptacle) names are the names of the associations.
Association with <<CORBAManages>> between HomeImplDef and ComponentImplDef is needed, otherwise you can’t navigate and define what HomeImplDef manages what ComponentImplDef.
Figure6: associations described Event ports have to be composite associations.
Nature of Problem
The section 8.4.4 ChemSearchEngine class includes the following method:
searchChemicalElements():Collection
This is also shown in the figure 8.32. However the figure has a dependency from the ChemSearchEngine class to the ResultSet class.
The Java API, in lifesci/05-08-03, correctly shows the return value for the method as ResultSet.
Proposed Solution:
Change the figure and text in section 8.4.4 to agree with the Java API.
Should the interfaces that accept a wstring also somehow state the maximum length of that data string? This is necessary for the implementation to know the maximum number of wide characters that may need to be stored in a persistence repository. e.g. Currency.mnemonic is three? This also includes the following : Currency.name, Currency.fractionName, Currency.symbol, Currency.fractionSymbol, Currency.description, Currency.ISOVersion, a locale wstring, ExchangeRate.rateType, CurrencyBook.publishedVersion, MoneyFormatter.formattingString, MoneyFormatter.groupingSymbol, MoneyFormatter.negativePrefixSymbol, MoneyFormatter.radixSymbol.
Summary: DAmountOfTime difference(in DTime anotherTime) does not support an
implementation properly as the difference between two points in time is a
DamountOfTime instance and DamountOfTime represents an “absolute (positive)
amount of time”. Thus, either DamountOfTime must be able to represent an
amount of time that is less than zero, or the following interfaces must be
available.
· Propose the following additional interfaces:
boolean equal(in CBO::Dtime otherObject);
void setEqual(in CBO::Dtime otherObject);
boolean less(in CBO::Dtime otherObject);
boolean lessEqual(in CBO::Dtime otherObject);
boolean greater(in CBO::Dtime otherObject);
boolean greaterEqual(in CBO::Dtime otherObject);
Summary: The toWeeks(), toDays(), and toHours()operations return the amount to the
nearest whole unit. The toMinutes() and toSeconds() operations are not
specified in the same way, and the commentary for these two operations uses
such poor English that the intention is not clear.
All throughout the spec it references ISO 4217:1995, it would be better to reference the latest ISO 4217 standard (i.e. no hard-coded date/year).
Summary: The equals/setEquals() interfaces accept a base class CORBA Object as the
parameter type. The instance passed must be narrow’ed to a DDecimal, DTime,
etc. for the interface to carry on with its task. This is not possible as
the Ddecimal, Dtime, etc. are not IDL Interfaces, they are IDL Value types.
Since an IDL Value type does not derive from Object, the narrow’ing is not
possible. This also affects other portions of the CBO
DCurrency, DMoney,
etc. Also, equals(in Object anObject) causes a problem in a Java
implementation as every Java class inherits from java.lang.Object. The
boolean equals(Object obj) method supported by java.lang.Object cannot be
overriden AND additional throw an FbcException. Thus, equals(), setEquals()
should be changed wherever defined to be equal(), setEqual().
Summary: The CBOException type currently prohibits the called software from
informing the calling software as to the source of the problem that raises
a CBOException. e.g. If CBO::DTime::setSeconds(63) is called, a
CBOException will be raised, but the caller cannot query the CBOException
caught for its exception type or description as CBOException does not
currently support these constructs. In the case where many arguments are
presented to a method, the caller will not know which specific argument is
causing the problem.
Summary: The Currency submission indicates that a specific Currency instance that
does not have an expiration date will be noted with an expiration date of
99/99/9999. This attribute is handled via a CBO::Dtime instance, but a
CBO::Dtime instance cannot be created or mutated to represent 99/99/9999.
e.g. The CBO::Dtime::setMonth(mon) expects 1 <= 12, etc. Would probably be
easiest to have two operations on CBO::Dtime to handle this. These could
be:
void setUnspecified() might be handled in an implementation as
99/99/9999.
boolean isUnspecified() insulates the consumer from knowing how
the notion of “unspecified” is implemented.
Summary: The setYear(in long year) interface is described such that year is
expressed in four digit form. Does this then mean that year must be >= 1000
or that year indicates an absolute year after christ? e.g. 99 means 99 and
not 1999?
Summary: Cannot set precision to something other than milliseconds, as DAmountOfTime
cannot represent sub-second resolution. Cannot set the millisecond portion
of the point in time as the Factory does not take the number of
milliseconds as an argument, nor does the init() method.
Summary: Should the subsystem/singleton components (i.e. StateIdManager,
CurrencyBook, ExchangeRateManager, MoneyFormatter, MoneyCalculator) all be
published separately to the CORBAservices Naming Service?
Summary: Text needs to be added to describe what causes an exception to be raised
for a given interface, when the semantics/preconditions for the interface
have been violated (vs. exceptions specific to a vendor
’s implementation).
e.g. Money.[gs]etValue(), MoneyFormatter.[gs]etFormattingString(), etc. It
appears that most every interface raises (FbcException), but quite often
the text which describes which exceptions can be raised, in terms of
ExceptionType and under what conditions the exception is raised/thrown, has
not been detailed. A detailed pass through the entire FbcCurrency spec
should be conducted with attention paid to each interface and its exception
generating details.
Summary: Now that the CBO submission no longer exists, we need to add the text for DTime and DDecimal
from the CBO submission into the Currency Spec.
Summary: Issue Description: Clarify comparisons of two CBO::Ddecimal values on
equality (i.e. 2.0 equal to 2.000)
regardless of scale factor.
The binding of CORBA System exception is not complete , regarding WSDL 1.1 (see http://www.w3.org/TR/wsdl#_soap:fault Each occurrence of : <fault name="CORBA.SystemException"/> must be replaced by : <fault name="CORBA.SystemException"/> <soap:fault name="CORBA.SystemException" use="literal"/> </fault> More details on http://rt.cpan.org/Ticket/Display.html?id=30893
The QueryAccess interface has a matching interface called AsynchAccess which mirrors many operations in QueryAccess except the data is returned asynchronously. FCPR is looking at the ConstraintLanguage interface for doing population studies. The time needed to find and return the data from these types of queries could be significant. Yet these calls are synchronous. It may be useful to mirror this interface with one that has corresponding asynchronous operations. Additionally, the interfaces could be expanded to allow for clients to check on the status of their request.
There is one enhancement that will be treated in a separate issue paper: that of using another mechanism for the delivery of observation data such as XML or an IDL instead of the current nested ObservationData structure. For now we will simply mention that this is an area that needs to be enhanced. Massive amounts of data being moved across in the QueryAccess services need metadata or more descriptive access for clients to decode the data. We have suggested using XML in the any portion of the observation data structure. A DTD could be used for clients to decode the data in then XML stream. This removes the burden from the client of having to understand the internal data structures of the data being passed back. COTS products could be used to unwind the data and display the required portions. Versioning would also be easier to handle using XML since different versions of the DTD could be used to decode different XML format versions.
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:
My preference is ??,
As mentioned in the previous paragraph, the IDL does not reflect the examples correctly in all cases, such as the Numeric data type. The entire IDL needs to be vetted to insure that the examples are accurately captured in the IDL.
The ability to specify qualifiers will be an important facet of the GCPR COAS Implementation. Thus the get_observations_by_qualifier call will be used to specify filters for the data being requested. Relational operators will be a key element of the inbound qualifiers on this call - for example to specify that the results include values greater than a specified value.
Though the COAS Specification shows that relational operators (greater-then, less-than, etc) can be specified for a value field, such as Numeric, in an optional component, the IDL does actually not contain any such optional field. Thus there is no current way to specify these relationships. Additionally, we suggest that the CodedElement class (subclass to ObservationValue) contain an optional field for relational operators. It is possible that a qualifier may include a coded element that needs such a relational operator.
The EventSupplier interface in COAS has one simple call for a client to receive events: subscribe. This operation allows a client to specify a sequence of subscriptions which are structures that include data on who and what the client is interested in. According to the specification, calling this operation will replace any current subscriptions made by a previous invocation. Thus this operation is not additive. We recommend that an additional operation be added which would allow subscriptions to additive - not replacing the current subscriptions but adding new ones. Conversely the ability to remove specific subscriptions would be required as well. GCPR will want to keep a cache of patient data up to date. The event interfaces may be useful for this purpose. As new patients are added to cache, servers could be notified of the new subscriptions. Without additive subscriptions, the client would have to resend the same subscription information on current patients already in cache each time a new subscription was needed.
"4. If the identifier is greater than 30 characters, then truncate right to 30 characters."
After this step there might be a hyphen at the end of the identifier. This should be truncated, too.
While skimming the CORBA->COBOL mapping of IDL constructs, I noticed an
anomaly in that unsigned integers are mapped to signed integers:
> IDL Name
> COBOL Representation Integer Range COBOL Typedef
>
> unsigned short
> PIC S9(05) BINARY 0 to 2^16 CORBA-unsigned-short
> unsigned long
> PIC S9(10) BINARY 0 to 2^32 CORBA-unsigned-long
> unsigned long long
> PIC S9(18) BINARY 18 numerics CORBA-unsigned-longlong
> enum
> PIC S9(10) BINARY CORBA-enum
>
> 1.4.1 Basic Integer Types
>
> The mapping of long long,
> and unsigned long long
> was made to PIC S9(18)
> and PIC 9(18).
Presumably the statement of section 1.4.1 is the correct one?
The integer ranges given are wrong, correct would be -2^15 to 2^15 -1 and -2^31 to 2^31 -1.
The COBOL Representation for short should be PIC S9(4) BINARY (which is 2 bytes) and for long PIC S9(10) BINARY (which is 4 bytes).
There are some different tessellation structures for different kind of entities (geometric and topologic) and some are for both (e.g. EdgeTessellationStruct). Three of the four structs have a obj_ref member with type Object.
Issues: 1. The type Object for obj_ref is too generic. 2. Some of the tessellation structs are for the use with one single interface (ConnectedFaceTessellationStruct -> Body) while some others are used in more than one interface (EdgeTessellationStruct -> Edge, Curve). 3. In some cases the obj_ref member of a single tessellation struct references a geometric entity (Curve, Surface), in others a topologic entity (Edge, Face, Body)
Proposed Solution: For each interface which provides tessellation (has a tessellate() method) there should be one corresponding tessellation struct with a obj_ref member of the type of the interface which generated the struct.
Edge -> EdgeTessellationStruct Face -> FaceTessellationStruct Curve -> CurveTessellationStruct Surface -> SurfaceTessellationStruct Body -> ConnectedFaceTessellationStruct
It would be much clearer that way and the redundancies pretty few.
In CadFoundation::EntityPropsStruct one variable is named ref_position in the pdf and ref_positions in the idl files. Should be ref_position
The CadBrep::OrientedEdge interface has two very similar methods to get the Face/OrientedFace which uses the OrientedEdge. That's pretty redundant. Besides: Both methods deliver useful information only when the OrientedEdge belongs to one and only one Face. Otherwise an exception is generated. I don't really see the usefulness of those two method, especially since for many cases there are two Faces for the Edge and one can always traverse there via the EdgeLoop.
In the CadBrep module there are almost always two ways to traverse the topology: from the top level entities like Body to the underlying entites like Shell, Face, Edge, ... and the other way. For example I can get from Face to the OrientedFace which aggregates the Face or I can ask the OrientedShell in which Body it is contained. This does not make much sense to me. I always thought the topology is more or less hierarchical with Body is composed of OrientedShells which has reference to Shell and so on.
Unless I am missing something important, it is just some not so small overhead to have all those relations at hand and being uptodate with them. I would place such things in a client for I see it as application specific, if it is neccessary or not.
2. The Documentation for CadMain::Model::unique_entities() and CadMain::Model::top_level_entities() says the only valid types asked for are geometric entity types but there is only mention and used CadFoundation::Entity (in the doc and in the return types). If this should really be only geometric entities, the return types could be CadBrep::BrepEntity and the documentation should be much clearer on what is allowd and what a invalid type.
CADServices 1.1
1. In The CadMain::Model interface there is no clear way to get the DesignFeatures of a Model. The only possible way would be via top_level_entities() or unique_entities(), but these calls are for geometric entities (so it is written in the documentation).
Proposed Solution: add a call "CadFeature::DesignFeatureSeq design_features()" to CadMain::Model. The DesignFeatures should be more clearly seperated from the BrepEntities as they are to different sights on the same data and should not be mixed per chance.
I have a problem understanding how to interpret the
> vertex_number's for
> the points in CadGeometry::EdgeTessellationStuct. I don't see
> the need
> for a indexing here. It is just sequencial. Are there people,
> who want
> to do this another way?
In the PDF document (03-02-02) for the CadServices the return value for CadFoundation::Entity::reference_position is CadUtility::PointStruct, but in the idl files it is CadUtility::PointStructSeq.
I couldn't verify it against the newest documents (maybe newer than mine), because they were unreachable.
Besides, the description of this method is not very helpful (at least to me). I have no clue how to interpret it.
after changing the fourth parameter of CadConnection::CadSystem::create_model from CadFeature::ParameterSeq to CosPropertySevice::Properties recently, the exception CadConnection::BadParameter does not match the method anymore.
It should either be changed in a similar manner or kicked out completely (it is only used by create_model).
The return value of CadFoundation::Entity::cad_model() is Object. It would be clearer if it would return CadMain::Model (forward declaration).
The method CadMain::Model::unique_ids_to_entities() can throw the CadMain::NotValidCadType exception but unlike the other methods able to throw this does not get TypeCodes as input. If the exception is there by accident I suggest it be removed.
In the PDF document for CADServices 1.1 (03-02-02) the description for CadMain::Model::unique_ids_to_entities() is missing
Where can one get the CadFeature::Parameter instances from to use in CadSystem::create_model() ?
As far as I know, the instance of a idl interface can only be created on the server (in a get method or in a factory) and I can see no way of creating empty CadFeature::Parameter instances.
Besides, why was CadFeature::ParameterSeq used on Model level (CadMain::Model::create_model(), CadMain::Model::get_parameter_set()) and not as in other places CosProperyService::Properties? It is not clear to me, what information is supposed to be behind these parameters.
This looks like a valid concern. We can fix this by using either CosProperyService::Properties in place of the CadFeature::ParameterSeq or we can created a CadFeature::ParameterFactory.
I suggest the use of Properties.
File CadMain:
1. Method add_child and remove_child from CadMain::Model should has
CadMain::ModelInstance in parameter instead of CadMain::Model.
File CadGeometryExtens:
1.
struct SurfacePatchStruct
;
Should be
struct SurfacePatchStruct
;
because parent_surface can be any type.
struct OffsetCurveStruct
{ double distance; CadUtility::VectorStruct ref_direction; boolean self_intersect; };
Should contain also field CadGeometry::Curve BasisCurve.
struct HyperbolaStruct
{ CadUtility::TransformationStruct location; double semi_axis; double semi_imag_axis; };
Should be moved from module CadSurface to CadCurve, because it is used
only by "curve"
interfaces.
Althrough I report my issue as a C++ issue, actually it is a common issue for other languages also. In current CORBA standard, a activated CORBA Servant object in the POA is shared by all the clients. But in many applications, a client connects to the server and calls some CORBA object methods to create a lot of connection related CORBA objects. Normally, the client will call "destroy" method of these CORBA object to destroy them before existing. But if the client exists abnormally, these created CORBA object will never be destroyed and never be used by any client. We can call this kind of CORBA object as "floating" CORBA object. The CORBA server application runs longer, the "floating" CORBA objects becomes more. And eventually, these "floating" CORBA objects will consume all the memory resources/CPU resources, then the CORBA server crashes and has to be restarted. The "floating" CORBA objects problem at the server side is not easy to be solved. For this problem, if the CORBA standard provides a method to solve it, the CORBA server will run more robust. Actually, the underlying network connection broken can be detected very effectively and rapidly. The CORBA server just simply ignores the network connection lost event and does not pass it to activated CORBA object even if the CORBA object is connection related object because current CORBA standard thinks that all the CORBA objects in the server are shared to all clients. If the server can notify the network connection lost event to the connection related CORBA objects, the developper can do the clean job on it. A simple method can solve the "floating" CORBA object problem. It is not required to add any new interface or data structure to current orb.idl. It is just required to add some new language mapping methods at server side only. I will give an example in C++ to show this simple method. A IShared,IConnSpec and IOtherConnectionSpec interfaces are defined below: interface IOtherConnectionSpec
{ ... }interface IConnectionSpec
{ IOtherConnectionSpec someMethod(); }interface IShared
{ IConnectionSpec createConnSpec( in string param ); }; These interfaces will be used in this example. 1) the IShared will be shared by all the clients, it is activated like this: SharedImpl sharedImpl( ... ); ... sharedImpl._this(); 2) add new mapping method for the "POA_IShared::createConnSpec()" like this: IConnectionSpec_ptr POA_IShared::createConnSpec( char* param, const ConnectionContext& connCtx ); In this method, a parameter named ConnectionContext that represents the connection between the client and server is added. This method has a default implementation like this: IConnectionSpec_ptr POA_IShared::createConnSpec( const char* param, const ConnectionContext& connCtx )
{ //just ignore the connCtx like the current CORBA standard defines return createConnSpec( param ); }3) If the user wants to create a connection related object, he/she must overload the "IConnectionSpec_ptr createConnSpec( char* param, const ConnectionContext& connCtx )" method and active the object with "this_( const ConnectionContext& connCtx )" method: IConnectionSpec_ptr POA_IShared::createConnSpec( const char* param, const ConnectionContext& connCtx )
{ ... IConnectionSpec *connSpecImpl = new IConnectionSpec( ... ); ... //use the connection related active method return connSpecImpl->this_( connCtx ); }in this method, the user uses the "this_( const ConnectionContext& connCtx)" method instead of the old "this()"" method to active the CORBA object. This activated CORBA object becomes a connection related object instead of shared object. Note: User can use the "this_( const ConnectionContext& connCtx)" method to active a shared object also. At this time, the ConnectionContext is a global variable "NO_CONNECTION_CONTEXT". 4) add a new mapping method named "getConnectionContext()" for every CORBA object. const ConnectionContext& IShared::getConnectionContext(); const ConnectionContext& POA_IConnectionSpec::getConnectionContext(); In this way, the IConnectionSpec can create and activate any other connection related CORBA object like this: IOtherConnectionSpec_ptr POA_IConnectionSpec::someMethod()
{ ... OtherConnectionSpecImpl *otherConnSpecImpl = new OtherConnectionSpecImpl(...); ... return otherConnSpecImpl->this_( getConnectionContext() ); //or ? //return otherConnSpecImpl->this_( this ); }5) add a new mapping method named "connectionLost()" for every CORBA object. When the network connection is lost, the CORBA server should find all the CORBA object associated with this network connection and call their "connectionLost()" method. The "connectionLost()" and its default implementation is listed below: void POA_IConnectionSpec::connectionLost()
{ //just delete this connection related object simply delete this; } void POA_IOtherConnectionSpec::connectionLost() { //just delete this connection related object simply delete this; }Because the SharedImpl object that created in the 1) step does not assicate with any connection, its "connectionLost()" method will not be called for ever.
The second-to-last paragraph of section 1.17.10.3 says
"For valuetypes that have no operations or initializers, a concrete type-specific factory class is generated whose implementation of the create_for_unmarshal function simply constructs an instance of the OBV_ class for the valuetype using new and the default constructor."
As specified, that requires the generation of invalid C++. The OBV_ class is abstract since it does not have implementations of the ValueBase reference counting functions.
Perhaps the intention is that the OBV_ classes in such cases should derive from DefaultValueRefCountBase. However, the wording and explanation in section 1.17.6 explicitly forbids this:
"Note that it is the application-supplied concrete valuetype classes that must derive from these mix-in classes, not the valuetype classes generated by the IDL compiler."
One solution that avoids the problem, and avoids restricting the application's use of the OBV_ classes is to generate yet another class that derives from both the OBV_ class and DefaultValueRefCountBase, for instantiation by the _init class's create_for_unmarshal function.
1.9.1 says:
"The copy constructor deep-copies any data pointed to by the T_var constructor
parameter. This copy will be destroyed when the T_var is destroyed or when a new
value is assigned to it. Compliant implementations may, but are not required to, utilize
some form of reference counting to avoid such copies."
and
"The normal assignment operator deep-copies any data pointed to by the T_var
assignment parameter. This copy will be destroyed when the T_var is destroyed or
when a new value is assigned to it. Assigning a null pointer to a T_var is legal and
results in deallocation of the data pointed to by the T_var."
So my question is, is it legal to use ValueBase::_add_ref() and _remove_ref() instead of _copy_value() in this instance when T_var is representing a valuetype?
C++ programmers will often want to use strings as
object identifiers, the C++ mapping provides several conversion
functions that convert strings to ObjectId and vice-versa:"
The purpose is so the programmer can pick an arbitrary natural language
string and use it as an ObjectId, not so that the programmer can
generate a randomly unreadable string out of a binary ObjectId.
[...] the C++ mapping provides several conversion functions
that convert strings to ObjectId and viceversa:
[...]
If conversion of an ObjectId to a string would result in
illegal characters in the string (such as a NUL), the first two
functions throw the CORBA::BAD_PARAM exception.
The conversion algorithm is not specified, and the ORB is free to
choose whatever encoding it likes for its Object IDs. (Object IDs
in stringified form need not be moved across address spaces (or,
at least, not across ORB boundaries), so having a proprietary
encoding is perfectly OK.)
Suppose we have:
typedef fixed<4,3> FT;
interface I
{ FT op(); };
Suppose the server does:
FT
I_impl::
op() throw(CORBA::SystemException)
There are lots more digits in the return value than what is expected by the
client. What should be returned to the client. The rounded value? The
truncated value?
Similarly, what if we have:
double d = 10000000;
return CORBA::Fixed(d);
Do we return 9.999 to the client (which is the best we can do in this case)?
Of course, it is the responsibility of the programmer to make sure that
nonsense such as the second case doesn't happen. But the spec has to say
what happens if it does happen
Also, the first case will be very common – what should happen in this case?
The Object::get_domain_managers() operation is a transmissible operation
with CORBA 2.3. Does ServantBase need anything added to handle this or
is this managed internally by the ORB/POA?
Footnote 11 on page 1-48 of the 1.1 version of the C++ language mapping states that sequence _var classes don't have a const version of "operator []". The justification in the footnote is incorrect.
This footnote should be removed, and the operator provided, since it otherwise prevents accessing sequence members through a const reference to a sequence _var.
Since the Any constructor from type code, void* value and boolean release flag has been eliminated, there is no longer any portable way to create an OUT argument for a DII request, without also assigning a value to it.
I propose either a constructor from type code or changing the behavior of the type code set method to always succeed if the Any's TCKind is tk_null.
Just as we prohibited direct extraction from any any into a _var type
due to the perils of memory management problems, we ought to prohibit
extracting into _out types of variable sized structured types for the
same reason
The addition amounts to a set of typedefs that would facilitate template
programming, added to each C++ skeleton class created for an IDL interface,
and analogous to the typedefs that already exist in the mapping for the stub
side. Say we have an IDL file
module foo
{
interface bar {};
};
Then in generated code we're talking about something like:
namespace POA_foo
{
class bar
;
};
need an _unchecked_narrow static operation that is similar to the _narrow. It will take in an object pointer but unlike _narrow will not check for compatibility before creating a new object reference.
In IDL it gives:
// IDL
valuetype V
;
But it should be
// IDL
valuetype V
;
implementing support for wchar/wstring I ran into some potential
problems with the UTF-8 encoding for the IDL 'char' type.
Lets suppose we have a C++ server with a native single-byte code set
like ISO 8859-1.
The Code Set Conversion specification states that UTF-8 is the fallback
code set for 'char'.
-> a client could decide to send characters in UTF-8 encoding.
What happens on the server side with UTF-8 encoded characters that use
more than 1 byte and thus don't fit into the single byte character as
specified by the C++ mapping for IDL type 'char'?
the C++ mapping should explicitly list operator == and operator Unable to render embedded object: File (= in the examples and text. If it is not allowed to use ==/) not found.= the methods should be declared private
On page 1-119, the spec says the following about _create_request() and
_create_request2():
[...] the ORB requires:
Note all the "optional" remarks.
It's not clear what "optional" actually means. We have two cases for
these parameters:
Two questions:
Where this is particularly annoying is for the return value. (The
"result" parameter to _create_request()):
I can call ORB::create_named_value(), but what should
I do then?
CORBA::NamedValue_var result;
orb->create_named_value(result);
At this point, I have a NamedValue containing an Any with
tk_null (because that's what the Any default constructor
creates). However, to correctly indicate that the operation
I want to call has a void return type, I have to make a
NamedValue that contains an Any with tk_void. But, how do
I achieve that? I can't use one of the Any inserters to
turn the TypeCode in the Any into tk_void, and I can't
use the type() member of the Any because I can't change the
type of an Any if it isn't consistent with the TypeCode that's
already there...
Even worse, the NamedValue doesn't seem to make sense as
the return value at all. For one, it has a name attribute.
Second, the NamedValue contains a flags attribute.
It seems that the easiest way to fix the problem is to state that, if a
parameter isn't needed, this is indicated by an empty sequence for lists,
and by a nil reference for objects.
However, the problems around create_named_value() and appear to be more
serious. How should we fix those?
The June 99 version of the C++ mapping doesn't mention ORB::destroy().
It should.
The second version of _create_request() accepts two context lists:
void Object::_create_request(
Context_ptr ctx, // <===
const char * operation,
NVList_ptr arg_list,
NamedValue_ptr result,
ExceptionList_ptr,
ContextList_ptr, // <===
Request_out request,
Flags req_flags
);
The spec then says:
The ContextList differs from the Context in that the former supplies
only the context strings whose values are to be looked up and sent
with the request invocation (if applicable), while the latter
is where those values are obtained.
So, I think (but I'm not sure), this means to say that:
If that is the intended interpretation, it's very difficult to discern
from the words in the spec now. I think this needs clarification.
Questions:
Also, looking at the ContextList interface:
pseudo interface ContextList
{ readonly attribute unsigned long count; void add(in string ctxt); string item(in unsigned long index) raises(Bounds); void remove(in unsigned long index) raises(Bounds); };
There is no further documentation on this. Some questions:
This seems insanely complex.
Suggestion: We should
Or, we could drop support for IDL context altogether (but I suspect we
can't get away with that
with 2.3, we got rid of all the C/C++ pseudo code for the DII and replaced
it with IDL. Unfortunately, this has broken something in the C++ mapping...
In the 2.0 spec, we had:
pseudo interface ORB
{ typedef sequence<Request> RequestSeq; // ... };
With 2.3, we changed this to:
module CORBA
{ // ... typedef sequence<Request> RequestSeq; // ... };
Unfortunately, the C++ mapping still shows the (now incorrect) definition
from CORBA 2.0 in Section 1.33.1.
In addition, the C++ mapping shows in Section 1.33.2:
class ORB {
public:
class RequestSeq
;
// ...
};
But then, in Section 1.41.21:
class ORB
{ public: typedef sequence<Request_ptr> RequestSeq; // ... };
The latter definition isn't C++...
So, we have several issues here:
1) How can we fix the C++ mapping to be in line with the core?
I'm toying with the idea of saying that RequestSeq is defined
in the CORBA namespace, with a typedef for backward compatibility
in the ORB interface. But I'm not sure what will break with
this kind of aliasing (repository IDs might change unexpectedly?)
2) Section 1.41.21 should be changed to show legal C++.
3) Depending on the resolution to this issue, both 1.33.2 and
1.41.21 will probably need updating to reflect the resolution.
what should _default_POA() return if the default ORB was never initialized?
The spec doesn't say...
I have the following questions to IDL - C++ mapping CORBA 2.3 (concerning valueboxes).
Can somebody give me an answer?
1. I assume that valueboxes T as a special kind of valuetypes also
need in C++ the T_var and the T_out types and the T_out types will be
used in function signatures for IDL out-parameters. Is it true?
2. The mapping for strings and wstrings requires a definition of C++
operators << and >> to allow a use of strings (wstrings) with the c++ iostreams.
What about valueboxes of strings (wstrings) - chapter 1.17.7.4?
Is it required to define (in C++) the operators <<, >> to use T_var and T_out
with C++ iostreams, where T is a type for a valuebox T of string (wstring)?
Given
valuetype WStringValue wstring;
is there any requirement to have stream inserters and extractors for the
boxed value type itself? The spec is currently silent on this issue.
Should the following work?
WStringValue ws;
cin >> ws;
cout << ws;
Incorporate Messaging changes relevant to the C++ mapping, as shown in
orbos/98-05-05 pages 115 and 116 together with any changes made to them
by the Messaging RTF, into the IDL-C++ mapping chapter.
quite some time ago, we added the _var_type and _ptr_type definitions
to proxies to make it easier to write templates. Similarly, we have
the _whatever_seq typedefs for recursive structs and unions, to avoid
problems with anonymous types.
What's missing at the moment is a similar feature for _var types.
When I'm writing a template that does it's job in terms of _var types,
I also quite often want to do something to the underlying target type
of the _var. However, I can't do that unless I pass in an extra template
parameter (which, in turn, doesn't always work if I also want to use
STL standard binders and such...)
So, why not add a typedef for the target type to every _var type?
the spec is currently not terribly clear about the server's responsibilities
when throwing an exception from an operation that has a variable-length
out param.
The intent of the spec is that the server is responsible for deleting
the memory it allocated to an out param before it throws an exception:
// Correct implementation
void
Foo_impl::
op(CORBA::String_out out_p) throw(CORBA::SystemException)
// Incorrect implementation
void
Foo_impl::
op(CORBA::String_out out_p) throw(CORBA::SystemException)
However, the spec never states this clearly. In fact, it sort of says
the opposite. On page 1-110, table item 3:
To maintain local/remote transparency, the caller must always
release the returned storage, regardless of whether the callee
is located in the same address space as the caller or is located
in a different address space.
There is no mention here of what should happen in the presence of exceptions.
I think it would be nice to clarify that the skeleton will never look
at an out param in the presence of exceptions and that the operation
implementation is responsible for deallocating memory in this case.
in the resolution to issue 863, we decided to get rid of the read-only
restriction for parameters. However, we forgot to remove a few snippets.
Page 1-110, table, case 3:
Remove the following text:
Following the completion of a request, the caller is not allowed
to modify any values in the returned storage--to do so, the
caller must first copy the returned instance into a new instance,
then modify the new instance.
Page 1-110, table, case 6:
Remove the following text:
Following completion of a request, the caller is not allowed
to modify any values in the returned storage--to do so, the
caller must first copy the returned array instance into a new
array instance, then modify the new instance.
Section 1.17.11 of ptc/2000-01-02 says that DataInputStream &
DataOutputStream are mapped according to the normal valuetype mappings.
This mapping results in operations that are at best cumbersome to use in
marshalling sequences of primitive types:
Operations read_xxx_array and write_xxx_array are defined, taking argments
of type CORBA::xxxSeq. These are obviously intended to be sufficient for
marshalling all defined sequences of the corresponding primitive type xxx.
However, the c++ mapping for sequences requires that each distinctly
declared sequence type be unique and separately overloadable. This
guarantees that a marshaller attempting to marshal an sequence of primitive
other than CORBA::xxxSeq will not be able to pass that sequence to the
corresponding read_xxx_array and write_xxx_array operations. Instead, code
must be written to bypass strict typing.
To fix this, either the mappings for DataInputStream and DataOutputStream
need to be non-standard, the mapping of sequences needs to change, or the
mapping of CORBA::xxxSeq needs to change to something special.
the text for set_servant doesn't say what should happen if I call
set_servant(0). I would suggest to throw BAD_PARAM in this case.
For servant reference counting, the words "at least once" appear
in a number of places when it comes to servant activation. set_servant(),
activate_object(), activate_object_with_id(), servant_to_id(),
servant_to_reference(), and _this() all use this language (pages 1-137 and
1-138):
... will invoke _add_ref at least once on the Servant argument...
Problem: suppose my ORB calls _add_ref() twice in each of these operations
for some reason. I now have a problem. That's because, for servant
activators, responsibility for calling _remove_ref() passes to
etherialize(). However, if the ORB is permitted to call _add_ref() as
many times as it likes, I have no idea how many times I have to call
_remove_ref() from within etherealize(). I think that the spec should say
that _add_ref() is called exactly once for these operations if the
corresponding servant is not in the AOM already.
I vaguely remember the discussion about optimization of the calls
to _add_ref() and _remove_ref(). I think the idea was to permit the ORB
to avoid redundant calls. However, it seems that the language in the spec
isn't precise enough. Under one interpretation, the refcount counts
the number of entries in the AOM. Under another interpretation, it counts
the number of calls in progress as well (because an ORB could call _add_ref()
when a call is dispatched and call _remove_ref() when it finishes).
Under yet a third interpretation, the refcount counts the number of
object references in my address space. That interpretation is happens
if every call to _this() calls _add_ref()...
The language is not precise enough, I think...
I believe the specification for insertion of object references to Anys is
somewhat ambiguous. And, if it is intended to be as I think, it may also be
less than ideal.
Consider the following idl:
interface B
{...};;
And then consider the following code:
D_ptr d; // initialize this to non-null value somehow
B_ptr b = B::_narrow(d);
Any ab;
ab <<= b;
Any ad;
ad <<= d;
// ...
B_ptr b_val;
if (ab>>=b_val)
; // 2
D_ptr d_val;
if (ab>>=d_val)
; // 4
>From what I can see of the spec, it is a bit unclear about whether then
insertion of an object should use the static type or the dynamic type of the
object to initialize the typecode. Simplicity and consistency with other
related operations suggests that it should use the static type. That is what
we currently do, and a quick test of ORBIX 2000 seems to tell me it does it
that way too.
With that interpretation, 1&4 will work, while 2&3 will fail.
Nobody should be surprised that 3 fails, but it is inconvenient
that 2 doesn't work.
If insertion used the dynamic type of its argument, then 1&2
would work, while 3&4 would fail.
To get reasonable behavior when derived types might be present,
(and how often can you be certain they cannot?)
it seems that one should almost never use type specific object
extraction. Instead, one must do something like:
Object_var o;
B_var bv;
if (ad>>=to_object(o._out()) &&
!CORBA::is_nil(bv = B::_narrow(o)))
;
This is unfortunately a bit inconvenient.
So, is there any text in the spec that says, when inserting an object
reference type into an any, if the repository id in the typecode should be
the static type of the inserted argument or the dynamic type of the value of
the argument?
If not, I think we need to add some text.
The C++ "Mapping of PortableServer Dynamic Implementation Routine" states
that "If DynamicImplementation::_this() is invoked outside of the context
of a request invocation on a target object being served by the DSI servant,
it raises the PortableServer::WrongPolicy exception".
This conflicts with the behaviour of _this() in static skeletons as de-
fined in "Skeleton Operations".
In particular, this means that DSI servants cannot be implicitly acti-
vated, and therefore, the choice of DSI vs. static skeleton is not trans-
parent to the application integrator.
Is there any rationale behind this?
I seem to remember that we decided to deprecate the void * functions
on type Any. However, looking at the latest C++ draft, they are not
marked as deprecated.
Can anyone remember what we decided to do? Is this a bug in the spec
or a bug in my memory?
C++ issue #1: The C++ specification should state that valuetype
parameters which are copied by the ORB for collocated invocations are
done using an ORB internal mechanism, not _copy_value().
The CORBA 2.3 C++ mapping is clear on what the use of
ValueBase::_copy_value is, but is unclear as to who is responsible for
providing an overriding definition of this pure virtual function. Is
it the IDL compiler, generating an overriding _copy_value() function for
each valuetype C++ class, or is the user, when he provides a valuetype
implementation class?
C++ issue #2: The ValueBase::_copy_value() function should be
deprecated in favor of a new ValueBase::_clone_value() operation:
// IDL
module CORBA {
abstract valuetype CloneContext { };
};
// C++
namespace CORBA {
...
class ValueBase
;
...
};
The _clone_value() function provides an independant copy of the
valuetype it is invoked on. Any valuetypes reachable via the state of
the original valuetype are also copied, and relationships between
original valuetype(s) will be preserved in the cloned copies. The
CloneContext argument provides the necessary state information for the
ORB to properly maintain relationships between copied valuetypes. If
_clone_value() is called with a null CloneContext, a new CloneContext
will be generated and returned by the ORB as a result of the call.
The CORBA 2.3 C++ specification, section 1.22 states that valuetypes
passed as in parameters to an invocation of an object are copied, even
if the object is collocated with the caller. It does not make this
statement for inout or out parameters (or return results), which
strongly suggests that valuetype copying is not necessary. In fact, the
text for valuetype inout parameters strongly suggests that copying is
not performed.
I think this is wrong and inout & out valuetypes should be copied as
well (inout parameters should be copied before and after the invocation,
while out and return values should be copied after the invocation
completes.) Without the copies, call transparency will be broken and
the client can distinguish between a local and a remote call.
The mapping for user exceptions and structures is identical, except
for one thing: user exceptions have an additional constructor with
one parameter for each member, so I can construct and throw the exception
with a single throw statement.
However, structures are second-class citizens: I can't instantiate and
initialize a structure at the same time. (Well, at least not in general,
because static initialization only works for aggregates and, at any rate,
I can only instantiate and initialize with compile-time constants.)
So, why don't we add the same constructor to the mapping for structures?
It seems inconsistent to have one mapping for structures and a slightly
different one for exceptions, when in fact they both could be the same.
Summary: This may be a naive question, but it seems like the C++ mapping
for value boxes is incomplete. As far as I can tell, the specification
defines the mapping for the following types:
basic types, enum, objref, string, wstring, struct, union, sequence, array, fixed, any
But what about the types that have not been mentioned?
value, value box, TypeCode, Principal, native, except
If these types aren"t allowed, does the specification say that somewhere?
Summary: We all know that the names of the C++ #include files generated from IDL are
not standardized, and are thus the one remaining major source portability
issue. One way to fix this would be to agree on some standard filenames,
but we"ve tried this before and have never succeeded.
Just thinking out loud here, but another way to fix it would be to agree on
some standard macro names that applications could use to portably include
the appropriate files. For example, define one macro for a client-side
include and one macro for a server-side include, both taking the basename
of the IDL file as an argument:
#ifndef CORBA_CXX_CLIENT_INCLUDE
#define CORBA_CXX_CLIENT_INCLUDE(base) <base ## Client.hh>
#endif
#ifndef CORBA_CXX_SERVER_INCLUDE
#define CORBA_CXX_SERVER_INCLUDE(base) <base ## Server.hh>
#endif
Obviously, the exact definition of the macro would depend on the names of
the generated files.
I believe these could then be used portably in the client and server source
code like this:
#include CORBA_CXX_CLIENT_INCLUDE(file)
With this approach, nobody has to change the names of the files they
currently generate.
Summary: Consider the following IDL:
----------------------------------------------------------------------
// IDL
typedef long MyArray[1000000];
interface I
;
----------------------------------------------------------------------
Now let"s assume that I want to implement this using the DSI:
----------------------------------------------------------------------
// C++
void
I_impl::invoke(ServerRequest_ptr request) throw()
{
String_var name = request -> op_name();
if(strcmp(name, "set_array") == 0)
{ NVList_ptr list; orb -> create_list(0, list); Any* any = list -> add(ARG_IN) -> value(); XXX request -> params(list); MyArray_forany arg; *any >>= arg; ... // Do something with arg; return; }else
{ NVList_ptr list; orb -> create_list(0, list); request -> params(list); Any* any = new Any; *any <<= new BAD_OPERATION(); request -> exception(any); } }
----------------------------------------------------------------------
At the line I marked with XXX, I have to set the TypeCode of the
Any.
Summary: Michi Henning & Steve Vinoski have previously challenged people to come
up with a modification to the C++ language mapping that would allow for
type safe widening of object reference _var types for assignment or copy
construction. I believe I have come up with the solution, and Michi
agrees with me:
Proposal:
For object reference _var types, replace the copy and assignment
operators:
class T_var
{ public: ... T_var(const T_var &); T_var &operator = (const T_var &); ... };
with:
class T_var {
public:
...
template <class C_var>
T_var(const C_var &cv) : ptr_(T::_duplicate(cv.in()) {
}
template <class C_var>
T_var &operator = (const C_var &cv) {
if ((void *)this != (void *)cv)
return *this;
}
...
private:
T_ptr ptr_;
};
Summary: There seems to be nothing in the spec that specifies the name of the include files for things in the CORBA module (e.g. type definitions). Add such a requirement to each language mapping
Summary: In a number of places in the sample code for the C++ binding, the symbol
_ptr is used as a member variable in _var types. In all of these the
actual member is shown as private, so it is clear that actual
implementations could use something else.
The one exception to this is in section 20.10 on the Mapping for Struct
Types. This discusses (without sample code) the mapping for string and
object reference members of structs.
Summary: The current C++ chapter for custom marshalled values on p. 20-94 lacks
information about how one implements a custom value.
The "Value Type Semantics" chapter in "ptc/98-10-06, 15 Oct. 98[REVIEW]"
p. 5-11 says,
" The implementer of a custom value type shall provide an
implementation of the CustomMarshaller operations. The manner
in which this [sic] done shall be specified for each language mapping..."
Summary:
The C++ mapping does not permit extraction of a Fixed from an Any
in a generic way – I must always specify matching digits and scale in
order to call Any::to_fixed(). This is inconvenient if an application
wants to deal with Fixed values generically (because Fixed is a generic
type in C++ anyway).
Proposal:
Add an overloaded >>= operator for extraction of Fixed from an Any.
The operator sets the Fixed value to whatever scale and digits
are present in the type code.
Cheers,
Michi.
Summary: The mapping right now offers Any::to_fixed to get a Fixed value out of an Any:
to_fixed(Fixed &f, UShort d, UShort s);
The spec doesn"t state what should happen if the digits and scale do
not match what is in the type code. I believe extraction should fail in
this case.
Summary: Section 20.9, page 20-28 of orbos/98-07-12 describes what types are
considered variable-length. Since the new Fixed class has non-trivial
constructors, it should also be a considered a variable-length type. Note
that any fixed-length struct containing one cannot be statically initialized.
Summary: There is no mention of PortableServer::ValueRefCountBase after this
page. It is not clear why values that also implement interfaces
do not use the same reference counting scheme as other values.
Summary: The C++ mapping document (98-09-03, p. 108) states that "... the callee
shall receive a copy of each valuetype argument passed to it even if the
caller and callee are collocated in the same process."
In the collocated case, should the ORB invoke _copy_value() to produce
the copy?
Since the user could implement _copy_value() to return a nil value, it
seems unlikely that the ORB could rely on this mechanism. However, a
properly implemented _copy_value() would likely provide a significant
speed improvement over marshalling and unmarshalling.
Summary: Section 20.21, "Argument Passing Considerations," says that for valuetypes:
"The caller shall eventually invoked _remove_ref on the valuetype
instance it receives back as either an inout, out, or return value."
For memory management purposes, this is not sufficient in some cases.
Summary: What happens if I write
CORBA::Any a = ...;
const char *p;
a >>= p;
and the type code in the Any indicates a bounded string? Does the extraction
succeed or fail? The mapping doesn"t say.
The semantics for insertion of a valuetype into an Any are unclear.
(Note, this is related to issue 2531 in the IDL-to-Java RTF.
It is also related to orb_revision issue 3205.)
In section 1.16.2 of ptc/2000-01-02, two forms of insertion are defined:
copying and non-copying. The non-copying form is described as:
"The noncopying valuetype insertion consumes the valuetype pointed to by the
pointer that T** points to. After insertion, the caller may not access the
valuetype instance pointed to by the pointer that T* points to. The caller
maintains ownership of the storage for the pointed-to-T* itself."
There is no specific description of the copying form specific to valuetypes,
so the generic description must apply:
"For the copying version of operator<<=, the lifetime of the value in the
any is independent of the lifetime of the value passed to operator<<=. The
implementation of the any may not store its value as a reference or pointer
to the value passed to operator<<=."
One possible interpretation (1) is that the copying form should be
implemented via a call to the _copy_value virtual function, while the
non-copying form should simply retain the provided pointer (without calling
_add_ref) and eventually call _remove_ref when done with it.
If so, what is the significance of the rule about the caller not continuing
to use the pointer? It it only that it has lost a reference count, and may
continue using the pointer if it has another reference count? Or does this
imply that continued access to the value is forbidden regardless of
reference count?
Another possible interpretation (2) is that the description is nonsense, and
that the non-copying form should use _add_ref and the copying form should
use _copy_value. In this interpretation the caller would be free to continue
using the original pointer and would be obligated to _remove_ref it
eventually. This seems like a more practical interpretation, but is
inconsistent with usage for other non-copying insertions.
Suggested Resolution:
Replace the paragraph on non-copying insertion of valuetypes (quoted above)
with:
"The noncopying valuetype insertion takes ownership of one reference count
to the valuetype pointed to by the pointer that T** points to. After
insertion, the caller should treat the pointer as if _remove_ref had been
called on it. The caller maintains ownership of the storage for the
pointed-to-T* itself."
"For copying valuetype insertion, the lifetime of the value in the any is
independent of the lifetime of the value provided. The implementation of the
any shall duplicate the value using the virtual function _copy_value or an
equivalent mechanism. The caller retains ownership of the T* pointer and
remains obliged to call _remove_ref on it."
The mapping is currently a bit ambiguous about the insertion/extraction
operators for Any. It says:
Assuming that boolean, char, and octet all map the C++ type
unsigned char, the private and unimplemented operator<<= and
operator>>= functions for unsigned char will cause a compile-time
error if straight insertion or extraction of any of the
boolean, char, or octet types is attempted.
This is ambiguous. It is not clear what is qualified by the first part
of the sentence "Assuming that...". It could qualify all of the paragraph,
in which case the interpretation is:
Only on platform where these three types indeed map to the same
C++ type will it be necessary to have these unimplemented operators.
// C++ Octet
oct = 040;
Any any;
any <<= oct; // this line will not compile
any <<= Any::from_octet(oct); // but this one will
This is unambiguous, but it doesn't make it clear whether this will be
the case for all mapping implementations, or only those where the
IDL types map to ambiguous C++ types.
It is important to note that the previous example is only one
possible implementation for these helpers, not a mandated one.
Other compliant implementations are possible, such as providing
them via in-lined static any member functions if boolean, char,
and octet are in fact mapped to distinct C++ types. All
compliant C++ mapping implementations must provide these helpers,
however, for purposes of portability.
Again, this is slightly ambiguous because, even though it requires the
presence of the helpers, it doesn't make any statement about whether the
prohibition of the direct insertion operators is mandatory for all
implementations.
I would suggest to clarify the text to state that direct insertion/extraction
of Bool, Octet, and Char must fail with a compile-time error, regardless
of how these types are mapped.
Question: Is it legal to do the following if I use a C++ mapping that
uses C++ exceptions instead of using CORBA::Environment to
handle errors?
CORBA::Environment my_env;
The spec says (page 114):
The C++-PIDL specification differs from the C-PIDL specification
as follows:
[...]
Supports a default constructor that initializes it to hold no
exception information.
However, the class definition that follows does not show the
default constructor.
So, the text disagrees with the class definition that is shown because
"supports a default constructor" does not have a "may" or "might", so
the text would appear to make the default constructor mandatory for
both EH and non-EH mappings.
The C++ language mapping does not specify what criterion should be used to
determine the validity of a typesafe extraction from an Any.
The closest it ever comes is the statement in 1.16.3:
"In this case, the version of operator>>= for type Long must be able to
determine whether the Any truly does contain a value of type Long...".
There are two obvious candidates: the equal and equivalent operations of
TypeCode.
Proposed resolution:
Replace the first sentence of 1.16.3:
"To allow type-safe retrieval of a value from
an any, the mapping provides the following
operators for each OMG IDL type T:"
with:
To allow type-safe retrieval of a value
from an Any, the mapping provides an
operator>>= for each OMG IDL type T.
Each such operator returns a boolean
indicating success or failure, and if
successful, makes the value of the any
available via a user supplied argument.
The success of the operation is determined
by applying the
needs to be discussed. I believe there
are valid arguments for each.
I believe that the CORBA::release and CORBA::is_nil
functions that take a POA_ptr argument do not
reference the proper scope:
1.41.11 release and is_nil
// C++
namespace CORBA
Should be:
1.41.11 release and is_nil
// C++
namespace CORBA
I don't see in the specification where the scope
of POA_ptr is explicitly defined. But, I believe
that the correct definition of POA_ptr is in the
PortableServer namespace (i.e. the enclosing scope
of the POA class).
Then again I can't find anything in the specification
that asserts that any Foo_ptr type must go in the
immediately enclosing class or namespace containing
the Foo type. :-/
Also, if POA_ptr is in PortableServer when an ORB is
mapping of modules to classes the definition of the
above release and is_nil functions in the CORBA class
will be impossible.
So I feel compelled to ask:
Do we really need to have release and is_nil functions
for types outside of the CORBA module?
the new mapping for _var types for fixed-length underlying types shows:
T_var &operator=(T *t) {
if (t != m_ptr)
return *this;
}
This guards against self assignment when a pointer is assigned to the _var.
I don't think this is right:
MyStruct * p = ...;
MyStruct_var v = p; // OK
// ...
v = p; // Almost certainly an error
A_var &operator=(const A_var& a)
{ reset(p); return *this; } This is inconsistent: assignment of a _ptr to a _var reference
is not safe against self assignment, so assignment of a pointer
to the _var for a fixed-length type shouldn't be either.
Note that the other assignment operators are just fine – I'm only objecting
to testing for self-assignment for operator= with a pointer as the RHS.
(A nice compiler could even insert an assertions if a _var is assigned the
same thing that it already points at.)
the spec currently says (page 1-101):
Request invocations made through the DII may result in
user-defined exceptions that cannot be fully represented
in the calling program because the specific exception type
was not known at compile-time. The mapping provides the
UnknownUserException so that such exceptions can be represented
in the calling process: [...]
Here is a code snippet for the DII:
req->invoke();
if (req->env()->exception())
The para on page 1-101, by implication, says that:
It's not as clearly spelled out as this, but it can be implied from the
words on page 1-101.
This is bad. For one, it implies "action at a distance". For example,
linking the stubs for a user exception into a completely unrelated
part of the same binary (possibly via a library) would change
the behavior of the above DII call. Further, to make this behavior
happen would require some form of global initialization data structure.
In effect, there would have to be something that would let the ORB
know (globally) for which user exceptions stub code is linked in.
We rejected the need for global data recently in another context (for
the proposed extraction operator for user exceptions). For the same reason,
we should reject this here and mandate that, if I use the DII, all user
exceptions are always returned as UnknownUserException.
I think we have a defect/omission in the C++ mapping with respect
to exception safety. Consider a servant class with a constructor:
class FooImpl : public virtual POA_Foo
{ public: FooImpl(); // ... };
Consider what happens if FooImpl() throws an exception for some reason.
By the time FooImpl() runs, the base class constructor POA_Foo() has run
already. So, when the compiler deals with the exception, it invokes
~POA_Foo().
The problem arises because, in our implementation at least, ~POA_Foo()
checks if the reference count is zero and asserts if not.
There doens't appear to be any portable way to implement an object that
inherits from an abstract interface using the DSI in C++ without compile
time knowledge of the abstract interface. The basic problem is that I
can create an object reference from a POA, but there is no way to
convert the reference into an abstract interface reference so that I can
send it out on the wire.
We need some mechanism to coerce an object reference into an abstract
interface reference (with a runtime check) to make this work.
what should _default_POA() return if no default ORB exists in the server
(that is, ORB_init() with an empty ORB ID was never called)?
Summary: The ValueBase::_copy_value() function is included in the discussion
of the "reference counting interface" in section 1.17.5 of 99-07-41.
Later, the description of the reference counting mix-in classes
says:
"Each of these classes shall be fully concrete and shall completely
fulfill the ValueBase reference counting interface..."
However, I do not believe that the intent was to require the mix-in
classes to implement _copy_value().
Therefore I suggest one of two clarifications:
1) Move the discussion of _copy_value() out of the reference-counting
section, or
2) Specify which functions the mix-in classes are actually expected to
implement, e.g.,
"Each of these classes shall be fully concrete and shall completely
fulfill the ValueBase reference counting interface (_add_ref,
_remove_ref, and _refcount_value), ..."
the spec says (on page 1-23):
The T* constructor creates a T_var that, when destroyed, will
delete the storage pointed to by the T* parameter. The parameter
to this constructor should never be a null pointer. Compliant
implementations are not required to detect null pointers passed
to this constructor.
This seems broken for two reasons:
Foo_var fv(some_ref->op(my_corba_environment));
and op() raises an exception (which will be returned in the
environment), I'm hosed.
It seems that disallowing initialization from null pointer is some
historical hangover? I think the restriction should be removed.
In section 1.17.5, the C++ class for Valuebase does not show the
get_value_def operation.
Section 1.17.7.5 states: "Value boxes for these types [including Fixed]
map to classes that have exactly the same public interfaces as the
underlying boxed types...".
Does this also include overloaded operators that are defined in the
Fixed class?
It sure seems weird to allow some operators to work but not others:
// IDL
valuetype FixedVal fixed<5,2>;
// C++
FixedVal *fv = ...;
++fv; // legal?
CORBA::Fixed f = fv * 2; // illegal?
In the CORBA 2.3 spec, section 6.2, CORBA::AbstractBase is defined as:
module CORBA
{ native AbstractBase; };
This implies that the C++ mapping for AbstractBase when used as a
parameter is like this:
class DataOutputStream
{ // from CORBA 2.3, section 5.5.2 void write_Abstract(AbstractBase value); };
But section 1.18.1 of the CORBA 2.3 C++ mapping makes it clear that the
signature should be:
class DataOutputStream
{ // void write_Abstract(AbstractBase_ptr value); };
Now I know that DataInputStream & DataOutputStream can be special cased
to handle this, but if we need to add additional operations that use
AbstractBase in the future, it would be nice if this could be fixed to
behave consistently with the other native type mappings to C++.
Summary: The C++ language mapping chapter contains many blocks of IDL like stuff
with the comment
// IDL
in the first line, but the stuff in the block is not valid IDL for
various reasons:
Uses "pseudo" as an apparent keyword.
(ii) Contains declarations like
attribute exception exception;
I suggest that the comment "// IDL" be replaced by "// Augmented IDL
(see "Usage" on page x-y)" cross-referencing to section 20.23 Usage, so
that people know for sure that this is not IDL.
Furthermore, to make the claim in section 20.23 true, the declaration:
attribute exception exception;
should be fixed to be something else, or alternatively, the exceptional
use of exception should be called out as a specific augmentation of IDL
in section 20.23.
consider:
// IDL
struct VariableStruct
{ ... };
interface I
;
Then:
// C++
void
MyImplForI::foo(VariableStruct_out s)
void
MyImplForI::bar(VariableStruct_out s)
The freeing of memory for out params relies on the default conversion
by the _out constructor from a pointer to the _out type which, as a
side effect, frees the memory return by the previous call. However,
in this case, and _out param is passed to another call, so the
assignment operator runs, not the constructor:
T_out& operator=(T* p)
{ ptr_ = p; return *this; }The assignment operator doesn't free the previous memory, so we get
the leak.
Should the assignment operator be changed?
The mapping requires that it must be possible to insert CORBA::Exception
into an any (section 1.19.2).
Question: Is it possible to insert UnknownUserException into an Any?
If the answer is yes, what are the members of UnknownUserException, what
is its CDR representation, and what is its TypeCode?
If the answer is no, we should clearly state this and specify what happens
if I attempt to insert UnknownUserException into an Any.
OpaqueValue, a new native type introduced in Issue 2162 (void *
in DII Chapter) for add_arg, was never documented in any of the language
mappings. Language Mapping that claim that the DII interfaces map
according to regular rules need to provide mapping rules for OpaqueValue
and document it. The mapping would simply be OpaqueValue --> (void *) or
equivalent.
The C mapping says in section 1.9:
OMG IDL structures map directly onto C structs. Note that all OMG
IDL types that map to C structs may potentially include padding.
This is not as clear as it should be. In particular, a requirement should
be added to preserve the order of structure members as they appear in the
IDL.
Summary: What if user calls T_allocbuf for a bound sequence with a length that doesn"t match sequence constraint?Does this go undetected?. A related issue is issue # 108
Summary: Sequence buffers are allocated seperately from sequence which contain them, they can be released separately as well. Is this the job of the omnipotent CORBA_free?
Summary: Mapping for IDL typedefs was dropped between CORBA 1.2 and 2.0. It should explicitly stated. Restoring text from 1.2 mapping is probably sufficient
Summary: Loose specification of the #define generated for an exception id: Specification by example is never a good idea. The specification should be more explizit.
Summary: Generate a Seq_releasebuf function for sequence Seq of type T to perform any buffer internal release. Function is called by Seq_freebuf prior to free buffer pointer acc. to release flag
Summary: Generate a Seq_initbuf function to initialize a buffer for sequence Seq of type T. Seq__allocbuf allocates a buffer and calls seq_initbuf to initialize the allocated buffer
Summary: Define 2 functions, CORBA_exception_init and CORBA_systemException_init to initialize respectively user-defined exceptions and system exceptions to be raised
Summary: Table 22,p 14-20 of C mapping lists argument passing cases. In both cases(3+6) the value is either an out parameter or return value. How to handle CORBA_free as caller or callee
Summary: generate pairs of (E_init, E_alloc) and (E_release, E_free) functions for exception E with behavior similar to the corresponding functions defined for any type T.
Summary: State as undefined the behavior of a sequence as long as its Seq_init function (as specified in issue # 322) has not been called this function initializing the release flag.
Summary: Generate pairs of (T_release, T_free) functions for any type T T_release performs any internal memory release T_free calls T_release and frees the pointer argument
Summary: Para describes strategy an implementation will use for determining an exception TypeCode. Information not relevant to application developer. Mark as guidance to Implementor.
Summary: Para indicates that all the parameter memory is freed as appropriate when DIR returns. Who frees memory? If DIR frees memory, then change the wording as appropriate.
Summary: In the definition of CORBA_ORB_init environment parameter comes last and it uses env instead of ev. Same inconsitency in CORBA_ORB_list_initial_services/CORBA_ORB_list_initial_references
Summary: vec10 and CORBA_sequence_long: are these distinct types?Would they have distinct typecodes and distinct entries in the Interface Repository?
Summary: Spec contains mutually inconsistent example (p 14-11 and 14-13. P 14-13 suggests that C structure MUST be named CORBA_sequence_long instead and must be enclosed in #ifdef...#endif
Summary: Are we supposed to declare and define allocators for new sequence Type? What is acceptable, required, forbidden (in terms of functions)?
Summary: Sec 14.25.2: It"s not clear what happens if CORBA_BOA_set_exception is called more than once for a given object invocation. This should be specified.
Summary: Section D.7 describes the mapping for CORBA_any. Sun would like to replace current C mapping for Any with opaque type, i.e conforming applications may not access members of CORBA_any struct
Summary: In C mapping what is representation of "string" in _value field of an any? "char *" or "char **"? "char **" seems to be more applicable-usage requires an "_alloc" function
Summary: The spec mentions 2 allocation functionsfor sequences of "T". These should better be inside the same (or similar) #ifdef...#endif as the struct typedef
Summary: It refers to a "third case", but there are no cases described, and there are only 2 examples. What are the cases this paragraph refers to?
Summary: There is very probably a small error in the C language specification.
Below is what I wrote to the mailing list concerned with building the ORBit ORB. It
was confirmed by one of the main coders behind ORBit.
> This is something else, but I was more confused because the OMG "C language
> mapping" spec at page 19-39 really seems to contain an error.
> In that example, they also create an application specific servant structure called
> AppServant, and they set the finalizer using
>
> AppServant my_servant = ...
>
> my_servant.epv._base_epv.finalize = my_finalizer_func;
>
> That should really have been (at least, that"s what I think):
>
> my_servant.base.vepv._base_epv.finalize = my_finalizer_func;
>
> I hope you agree with me there, or else I"m probably getting out of touch with C.
Summary: I currently implement a subset of CORBA 2.0. Not CORBA-compliant in terms of C-mapping for arguments to pseudo-objects and real objects. Give clear statement on argument order for real objects
Summary: Sec 14.11 specifies generation of a buffer allocator for each sequence type of form T* sequence_T_allocbuf (CORBA_unsigned_long_len); very difficult to implement correctly.
Summary: Section 14.28.1, 14.28.2, 14.29: CORBA_string is not defined anywhere in the code sample. These should be typedefed as CORBA_char * or char *
Summary: Section 14.3: Reference is made to CORBA_OBJECT_NIL but there is no defined value for this. A value must be explicitly defined and typed
Summary: The first para of section 14.17 seems to have crept back after a deletion in a n earlier draft- it shouldn"t since it generalizes things (wrongly) which are properly described later
Summary: Spec. should be clear that the pointer passed in out parameters by caller should be uninitialized. This clarification should be in case (3) and (6) of Table 22
Summary: Mapping should be explicit about how release flag interacts with inout, out, and return parameter. There probably is arelated C++ issue
Summary: Sect.14.23: Section indicates that ORBs may restrict the scope of legal operations on pseudo-objects. Minimal subset of operations should be defined so port. applications know what to rely on.
Summary: Section 14.22: Al IDL compilers will generate a C language header. Does that mean that the C Language is required to be supported by all CORBA implementations?
Summary: Information on implementation strategies for pseudo-objects is not relevant to application portability. It should be removed or appropriately annotated as guidance for ORB implementors.
Summary: In case 5 of table 22 in section 14.19, what is the specified behavior if the release flag is FALSE, but the value to be returned is longer than the value specified?
Summary: When must this be done? always, whenever the release flag is TRUE, whenever the sequence elements contain secondary storage, whenever it is an out, inout, or return
Summary: Generate string literal for exceptions as the stringification of the macro name e.g.for exception E: /*C code generation */ #define ex_E "ex_E"
Summary: Generate a pair of (Seq_allocbuf, Seq_freebuf) functions, for sequence Seq of type T to manage resource of buffer sequences: Seqallocbuf and Seq_freebuf
Summary: Map sequence type names and sequence element type names enclosed within a scope according to the encoding scheme described as follows (/archives/issues/issue314)
Summary: Deprecate use of CORBA_free and generate T_free functions for any type T instead. Specification of T_free is current spec for CORBA_free suitable for type T
The Usage Context (in the PIM the applicableContext) is represented as an attribute of the ConceptDomainBinding class. applicableContext - a realm or context in which the particular binding applies. If not present, the binding applies in any context not stated in another binding.
In the SFM it is represented as a class entirely apart providing detailed information about the binding. If we have two different value sets belonging to the same Concept Domain but with different usage contexts, this cannot work. Moreover, in most implementation guides, the Concept Domains are not specified, indicting just the Usage Context as Concept Domains are something very specific to HL7 (they can be inferred), and the Usage Contexts are expressed as OIDs and not as URIs (enforcing the fact that we need the possibility to simultaneously define an entity via an URI and an OID)
Use Case:
The value set epSOSActiveIngredient 1.3.6.1.4.1.12559.11.10.1.3.1.42.24 consists of the whole ATC and it is the most important piece of information in the medication identification in epSOS. The same value set is being used in 3 different documents in 4 different sections with 4 different entries:
Prescription Item Entry 1.3.6.1.4.1.12559.11.10.1.3.1.3.2
Dispensed Medicine Entry
1.3.6.1.4.1.12559.11.10.1.3.1.3.3
Medication Item Entry
1.3.6.1.4.1.12559.11.10.1.3.1.3.4
Allergy & Intolerance Concern Entry
1.3.6.1.4.1.19376.1.5.3.1.4.5.3
Prescription Section
1.3.6.1.4.1.12559.11.10.1.3.1.2.1
Dispensation Section
1.3.6.1.4.1.12559.11.10.1.3.1.2.2
Medication Summary Section 1.3.6.1.4.1.12559.11.10.1.3.1.2.3
Allergies and Other Adverse Reactions Section
1.3.6.1.4.1.19376.1.5.3.1.3.13
In the follwing documents:
ePrescription
eDispensation
Patient Summary
Patient Summary
The corresponding Concept Domain is EntityCode and the subdomain is ActiveIngredientDrugEntityType for all four Usage Contexts; however they are entirely different. Logged: https://github.com/cts2/cts2-specification/issues/146
The PIM uses enumeration rather than having a code system of its own. This does not allow for new codes to be added easily (need another enumeration), a separate documentation is needed for the definition of what the enumerations mean, and translations are not possible. Two such examples are the enumeration Resource Type with 7 possible values such as CODE_SYSTEM, CODE_SYSTEM_VERSION, CONCEPT_DOMAIN, MAP, MAP_VERSION, VALUE_SET, VALUE_SET_DEFINITION and the enumeration CHANGE TYPE with the enumerations: CREATE, UPDATE, METADATA, DELETE, CLONE, IMPORT. It would good terminology practice for the international specifications of terminology server to use an internal code system rather than use enumerations. Logged: https://github.com/cts2/cts2-specification/issues/145
referencedEntity in SpecificEntityList is defined as "the namespace / name or URI of the entity to be included".
It should read "the URI and optional namespace/name and description of the entity to be included".
Logged: https://github.com/cts2/cts2-specification/issues/166
There is currently no way to extend a concept domain binding with tag/values. This prevents us from adding the HL7 codingStrength and effectiveDate attributes.
We propose extending ConceptDomain Binding to support a property attribute.
Logged: https://github.com/cts2/cts2-specification/issues/164
The EntityDescription model provides hooks for children and descendants, the interpretation of which is left to the service. Value Set Definition, however, provides no equivalent ability where, instead, the associatedEntities have to provide the specific predicate.
Would recommend making the predicate optional and, if present, describing the exact behavior that the service needs to exhibit.
Logged: https://github.com/cts2/cts2-specification/issues/165
The ValueSetDefinition SpecificEntityList states that "the service must include all entities in this list whether they are known to the service or not and whether they are ACTIVE or not".
We do not believe that this is correct – the service still needs to validate this list when constructing a resolved value set and should NOT allow invalid or non-active entries to make it into a "valid" resolved value set.
The SpecificEntityList description needs to be updated.
Logged: https://github.com/cts2/cts2-specification/issues/167
EntityDescriptionBase doesn't have a status element of type StatusReference. This prevents us from recording the organization's workflow status.
We propose adding a status element to EntityDescriptionBase.
Logged: https://github.com/cts2/cts2-specification/issues/163
The 'resolve' functions in ResolvedValueSetResolution lack a readContext - this is an oversight and needs to be corrected.
Logged: https://github.com/cts2/cts2-specification/issues/126
Rename method 'getKnownCodeSystems' to 'getKnownCodeSystem'.
Rename method 'getKnownCodeSystemVersions' to 'getKnownCodeSystemVersion'.
Rename method 'getSupportedVersionTags' to 'getSupportedVersionTag'.
In method 'restrictToTargetExpression' change the type of param 'target' to EntityExpression
In method 'count' add parameter 'timeout'.
In method 'getAllSourceAndTargetEntities' change the type of param 'directory' to EntityDirectoryURI
In method 'restrict' change the type of param 'directory' to DirectoryURI
In method 'restrictToTargetLiteral' change the type of param 'target' to String
Logged: https://github.com/cts2/cts2-specification/issues/50
In ValueSetDefinition.xsd in the complex type CompleteValueSetReference, the type for valueSetDefinition is wrong:
<xs:element name="valueSetDefinition" type="core:ValueSetReference" minOccurs="0" maxOccurs="1">
The type should be core:ValueSetDefinitionReference.
Logged: https://github.com/cts2/cts2-specification/issues/160
The type ValueSetDefinitionListEntry in ValueSetDefinition.xsd contains an incorrect cardinality:
<xs:element name="entry" type="ValueSetDefinition" minOccurs="0" maxOccurs="unbounded"/>
It should contain one and only one entry:
<xs:element name="entry" type="ValueSetDefinition"/>
The resource List (example CodeSystemCatalogEntryList) specifies that the contents should be represented as
<entry>
<entry ...>
<entry ...>
</entry>
This pattern is repeated across all lists.
Logged: https://github.com/cts2/cts2-specification/issues/161