On 30 Oct 2005 17:02:25 -0800, michael@[EMAIL PROTECTED]
wrote:
>
> Steve O'Hara-Smith wrote:
>
> > > If you're wondering where I'm heading with this, think of nested
data -
> > > like XML (only far more compact).
> >
> > If that's the goal look into ASN1.
> >
>
> Isn't ANS1 mostly about encoding data *type* - along with the data?
> That's a separate issue. I'm looking to handle nested delimited strings
> of any, or no specified, type. The data type (required for conversion
> to/from ASN1, say) of each delimited string, or group of strings, along
> with any other metadata such as markup, can be described or defined in
> an associated nested delimited string, or two, or three, or whatever.
>
Not inherently. ASN.1 is about encoding any structure defined in a
(specified) data language.
You could certainly do n-ary trees of character strings as array of
(discriminated) either string or (recursively) tree of strings. And
since these types have different primitive tags, you don't need any
added application tags. IIRC, may not be exactly right, I don't
currently have tools or references at hand to check:
StringTree ::= SEQUENCE OF CHOICE { IA5String, StringTree }
or to include the (trivial) case of only one string
StringTree ::= CHOICE { IA5String, SEQUENCE OF StringTree }
ASN.1 is frequently, I think probably more often than not, _used_ in
applications where it is desirable to encode data with type to allow
for extensibility and upgradability in distributed applications. For
example in crypto applications, the ones I have mostly worked on, when
we want to transmit or store a key, what is in the key depends on the
algorithm used, and we know from experience that over time new
algorithms will be created and wanted, so standards like X.509 and
PKCS 4, 10, 8/12 have ASN.1 constructs roughly equivalent to:
struct { OID-identifying-algorithm , data-depending-on-that-OID }
That way when some subset of the users and systems add a new
algorithm, the other ones can unambiguously recognize that it's
something they don't know (yet); and with only a little care in
defining the ASN.1 they can skip the data they don't understand, and
as long as they don't actually need to process that data (only store
or forward it etc.) can proceed OK without even being upgraded. This
is useful for applications that want it, but not mandatory.
That said, I basically concur with mwojcik: ASN.1 is _a_ choice, with
advantages and disadvantages; there are others. One of the features,
IMO often a disadvantage, it shares with XML is that both are designed
very generally, to handle essentially everything anybody wants, so
tools that handle that generality are usually complex and arguably
bloated. But if you don't use those tools and develop your own more
limited specific ones you (must) reimplement quite a few wheels.
- David.Thompson1 at worldnet.att.net
|
