[dfdl-wg] Issues: additional data types

[Robert E. McGrath]

+
+ 
+ My opinion on these is that they can be built out of the existing 
+ DFDL/XML components and that this is the correct way of handle them. The 
+ standard should provide a document that describes one or more ways in 
+ which these types can be achieved.

Precisely.  The critical thing is that there is a standard for how
to do it, so people can share.

+ 
+ > *2. Opaque (tagged)*
+ >
+ This is just a sequence of bytes... it may need to be hidden (the 
+ layering introduces a requirement for it to be possible to be explicit 
+ about what is visible at a particular layer). (I don't know what the 
+ current favourite way to do this is).

Well I think this is NOT a sequence of bytes, it is a single n-byte object.

I.e., you should not access individual bytes, you should not add one, etc.
You definitely shouldn't convert it to integers, and so on.

This is not difficult to to implement, you just need to define a
complex type that has a tag plus a payload (which can be a sequence
of bytes it you want). But the type is not a subclass of byteseq.

+ > *3. �Code�*
+ > 
[...] 
+ I don't understand what you mean.

Suppose the file contains data plus Java classes. The Java classes
need to be marked as a blob to be interpreted by JVM.  Again, it is not
an array of bytes because you can't convert it to integers, etc.

Here the important goal is to have a very standard way for a
reader to know what is intended.  I.e., a well-defined anotation,
along with clear instructions about how to use it.

Not especially difficult, but needs to be a standard to work.
---
Robert E. McGrath
National Center for Supercomputing Applications
University of Illinois, Urbana-Champaign
Champaign, Illinois 61820
(217)-333-6549

mcgrath at ncsa.uiuc.edu