[dfdl-wg] Issues: additional data types

[Mike Beckerle]

Hmm. If we take your example of a class file, then if I am the Java 
compiler then I really do want arrays of bytes as this data, and I append 
to them as well.

On the other hand if I'm someone dumping the symbol table of a class file, 
then I don't want the byte codes to be in arrays of bytes? Why not? I 
would be nice to use the exact same schema as is used ot create the file.

so, this feels inconsistent to me. 

I don't draw a distinction between a sequence of N bytes and an N-byte 
represenational-size object of undetermined type. Or rather, the 
difference is just of the intent of the person using it. 

Do you want a type where it is simply an error to access individual bytes? 
 I.e., so we can express the length in bytes but without expressing that 
you should/can access it byte by byte?

...mikeb

Mike Beckerle
Architect, Scalable Computing
IBM Software Group
Information Integration Solutions
Westborough, MA



"Robert E. McGrath" <mcgrath at ncsa.uiuc.edu> 
Sent by: owner-dfdl-wg at ggf.org
09/06/2005 12:39 PM

To
Martin Westhead <martinwesthead at yahoo.co.uk>
cc
dfdl-wg at gridforum.org
Subject
Re: [dfdl-wg] Issues: additional data types






+
+ 
+ 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/dfdl-wg/attachments/20050906/71c68c8c/attachment.htm