🚀 go-pugleaf

The SQL Access Group (SAG) has developed a version of RDA written
in ASN.1 for their use.  The most recent draft proposal from ISO used
the RON.  In talking with some of the members of SAG it seems that it
is generally felt that RON and ROS really don't offer much of value
and in fact have some limitations that make it more palitable to
simply work with ASN.1, using ACSE and otherwise accessing the
Presentation Services directly.

One of the limitations of the ROS that was mentioned is that there is
no provision for a performer to issue a request "unilaterally" to the
client.  I would like to understand why linked operations can't be
used or why it isn't more appropriate to extend the ROS to get the
desired functionality.  The concern is that apparently w.r.t. at least
RDA, there is movement to do away with the RON and ROS.  This seems to
me, if it is true, to be some what of a step backwards.

In looking at the ASN.1 spec of RDA from the SAG, the specification of
arguments, results, and errors are separated into choices rather than
being collected together on a per operation basis.  It is not clear
how tools can make use of this (procedural) style of specification
other than by the implicit correspondence of context specific tags for
each of the arguments, results, and error types.  It seems to me that
one of important benefits of the RON is that it binds the corresponding
argument, result, and (list of) error types together in the notion of
operation.  This is essentially an object-based specification
approach.  It seems to me that this promotes the development of tools
that help automate some of the control flow of an application (e.g.,
rosy and the various boilerplates.)

I would be most interested in other users views on this topic and any
information as to whether there really is such a movement away from
ROS and RON.  I am aware that there is some work on Open Distributed
Processing and thought that this was to be based on the ROS, presumably
with some extensions of the RON to support some form of structural
inheritance other than simply importing from other modules.