URC formats vs interfaces

[Daniel LaLiberte <[e-mail]>]

Ronald E. Daniel writes:
 > I have continued
 > to work on URCs, and have some stuff that I am about ready to
 > send to the URC list. People who want to see the rough notes
 > can take a look at http://www.acl.lanl.gov/URC/canonical.html

Good.  We are continuing on with URNs as well.  We need a BOF for URNs
at least.  Who wants to arrange that?

Regarding URCs and your canonical representation, that is certainly
better than the N2 (conversion between representation pairs)
alternative, but there is another alternative that should be
considered also.  Instead of returning data in any format, define an
interface to the data.  This alternative is somewhat the same since we
could have multiple interfaces, and N2 interfaces between interfaces
or a canonical interface.  But at least an interface allows you to
hide the actual format of actual data.

An interface to the URC data would let you have access to it remotely,
but whatever is actually sent to clients does have to be data in some
particular format - so we never really avoid the data format problem.
We can reduce the data format problem by sending only a few primitive
data types.

Another way to avoid data format problems is to return data as a black
box along with code that interfaces to the data.  But this actually
makes the problem worse in some respects because the format of the
code, and its semantics, and the environment for interpreting it would
all need to be standardized too.

Standardizing data format is the easy part, relative to standardizing
the semantics of the data.  I.e. what does each type of data mean, how
do I interface to it, etc?  So we never avoid the semantics issue
either, but we have to start somewhere, and standardizing data format
is a good place to start.

Well enough rambling for this morning...

dan