[
Lists Home |
Date Index |
Thread Index
]
Dennis Sosnoski wrote:
> I think that makes ASN.1 a reasonable "one-size-fits-schema"
> choice. A lot of the world is still not schema, though - and
> even for documents with schemas, would the ASN.1 approach
> handle arbitrary documents at runtime, or would it need to
> use pregenerated codecs?
Just as XML works well in both "schema-based" and
"schema-free" environments, it is critical that any alternative binary
encoding do the same. But, it is also useful to recognize that when
you're working with XML, you are never really in a "schema-free"
environment... Even if you don't have an application-specific schema,
you've still got the schema for XML itself -- the InfoSet [5].
If you have an application-specific schema, you can do all
sorts of optimizations in the binary encodings and get really great
compression as well as parsing efficiencies based on your knowledge of
the schema. When working with the Infoset alone, you can't get quite
as much benefit from a binary encoding, but for many (not all)
applications the benefit will still be great enough to justify the
effort. For instance, you won't get as much compression with an
Infoset based encoding, but you'll still usually benefit from having
counted length strings and other benefits that make parsing more
efficient. (We exploit these efficiencies at PubSub.com, for more
info see [1] below.)
As most folk now know, ASN.1 and XML Schema are pretty much
interchangeable for describing XML. What you can describe in one you
can describe in the other. If you've got an XML Schema, you can
translate it to ASN.1 using the ISO defined transformations and then
generate 'codecs" for either XML or any of the ASN.1 defined binary
encodings. Of course, if you don't want to work with the ASN.1 syntax,
there are number of vendors (like OSS Nokalva [2]) who let you skip
the ASN.1 stage and generate either XML or binary codecs directly from
the XML Schema. (i.e. the XML Schema to ASN.1 Schema conversion step
isn't necessary).
It is not necessary to have "pregenerated codecs" to work with
at least the ASN.1 defined binary formats. While it has traditionally
been the case that most ASN.1 work *does* use pregenerated codecs, you
can get "compile-and-go" systems (like OSS Nokalva's [3]) generate
codecs dynamically at runtime. Thus, a minimal system might be defined
to have a pregenerated "codec" for XML Infoset, so that it can work
with any XML that arrives, and then use "Compile-And-Go" to generate
schema-specific codecs as the need for them arises or as schemas are
discovered.
Just as you can generate codecs on demand, you would also make
the switch from XML to binary encodings on demand. i.e. you probably
wouldn't generate a binary codec unless you had a connection with an
endpoint that supported binary encodings. I assume that unless some
endpoint explicitly supports binary, you would normally just generate
XML codecs. Of course, your code shouldn't care which codec is in use
-- the interface to the codecs should be the same in all cases. (i.e.
your interface might be SAX and you just don't care which XMLReader or
XMLWriter implementations are being used...)
bob wyman
[1] Some discussion of the way we benefit from a mixed XML/ASN.1
environment at PubSub.com. I think we've got the first practical
demonstration of a mixed XML/ASN.1 or encoding-neutral environment.:
http://bobwyman.pubsub.com/main/2004/02/xml_asn1_and_th.html
[2] OSS Nokalva's XML/ASN.1 tools:
http://www.oss.com/products/xml.html
[3] OSS Nokalva Compile and Go for ASN.1 (I assume that they will be
supporting XSD directly in the future):
http://www.oss.com/products/cng.html
[4] Objective Systems. Another XML/ASN.1 vendor: (Note: In addition to
their other products, they offer a free ASN.1 to XSD converter.)
http://www.obj-sys.com/
[5] Sun's "Fast Web Services" rely on ASN.1 binary encodings for both
"Fast Schema" and "Fast Infoset":
https://jwsdp.dev.java.net/fast/
|
