CORBA35 — Implications of any/valuetype marshalling

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.