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 mcgrath@ncsa.uiuc.edu