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@ncsa.uiuc.edu> Sent by: owner-dfdl-wg@ggf.org
09/06/2005 12:39 PM
To
Martin Westhead <martinwesthead@yahoo.co.uk>
cc
dfdl-wg@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