[
Lists Home |
Date Index |
Thread Index
]
Stephen D. Williams wrote:
> I want to write an application that allows a form
> editor to define a data schema and data structure
> that mirrors the form with named fields. The
> application can create XML documents/objects with
> the new format and input data from a dynamic GUI.
> It sends the schema (optionally) and the XML form
> data objects to another process which dynamically
> interprets and displays them.
> Trivial with XML, or esXML because the structure and
> naming are integral and the library and application
> can produce and consume the data interpretively.
There is no reason you can't do this with ASN.1 as well.
Reading a schema is pretty much the same problem no matter what schema
language you're using. ASN.1, XML Schema, whatever,... it is just a
matter of code.
Building the parsers dynamically is also pretty easy. Even
though traditionally ASN.1 based applications have been "compiled,"
there is no inherent reason for this to be the case. For instance, you
can get a "Compile-And-Go" system from OSS Nokalva that creates
parsers based on ASN.1 on the fly -- just like you would from an XML
Schema. Thus, you have "no IDL compiling, no code stubs, no rebuilding
applications" or any of the other stuff you worry about in your
message.
> Even with XER, doesn't the ASN.1 have to be
> compiled into code at some point?
Why would this be necessary? If we can write interpreters
driven by XML Schemas, then it shouldn't be hard to imagine doing the
same for ASN.1. In any case, it has already been done. See the
reference to "Compile-And-Go" above.
There isn't anything weird or mysterious about ASN.1. It is
just another schema language. The distinctive thing about ASN.1 is
that it has been carefully designed to allow it to be mapped to a
large number of alternative encodings. Thus, it works just as well
with XML as it does with a variety of binary encodings.
bob wyman
|
