[
Lists Home |
Date Index |
Thread Index
]
Mike Champion wrote:
> 9/14/2002 8:26:35 AM, "Alessandro Triglia" <sandro@mclink.it> wrote:
>
> >
> >
> >
> >Comparing XML with ASN.1 is fundamentally meaningless.
>
> Understood. I was simplifying for the sake of pontificating.
> I meant "protocols in text format defined with XML technologies"
> vs "protocols using whatever format is most appropriate defined
> with ASN.1."
>
> >
> >Among other things, this allows exploiting the binary
> >encoding rules of ASN.1 to save bandwidth and CPU cycles
> wherever this
> >makes sense.
>
> "whenever this makes sense" being the operative phrase, right?
I actually meant "whenever" and "wherever". Since schemas in ASN.1 are
independent of the representation (whether it is XML or some binary
encoding), it is possible that the same application, running on
different points of a network, exchanges the same data either as XML
documents or as binary messages. By "wherever" I meant using XML in a
part of the network, and binary in another part of the network, at the
same time. There are applications that would benefit from this, to cope
with great differences in the bandwidth available on different segments
of a network. The XML-only nodes might run a program built with a tool
using pure XML technology, while the binary-only or XML/binary nodes
would run a program built with an ASN.1 tool.
Of course, the benefit to this is not only compact messages. There are
very good and mature ASN.1 tools out there, and many users comfortable
with these tools and with the language itself. Many of these users would
not switch to XML Schema without a compelling reason, but will find
themselves suddenly able to exchange XML messages (both among themselves
and with any other XML users) thanks to the recent standards development
efforts.
> My
> point was that to maximally leverage the network effect, it often
> makes sense to optimize something other than bandwidth and CPU
> in designing protocols and other standards, basically so that
> automated
> supply chains (or whatever) can be extended to very small players
> and devices at an affordable cost. That means that "hubs" can get
> into situations where all those messages that were designed
> to leverage
> mindshare, ubitquitous XML and internet tools, ease of
> deployment, etc.
> can be overwhelmed. THAT is the market that Datapower and all the
> other companies with similar products is trying to reach.
That also looks like one of the problems the ASN.1+XML technology can
help to solve. You would be free to use whatever tools you like to
leverage mindshare, ubiquitous XML and internet tools, ease of
deployment, etc. You would then be able to translate your schemas to
ASN.1, being assured that any program built on the resulting ASN.1
schema will interoperate with programs built on the original XML Schema.
Then, depending on the expected interaction schemes, you would be able
to choose the best technology (and options) on a node-by-node basis.
>
> So, I agree that comparing XML and ASN.1 is meaningless.
> Perhaps the world
> of B2B messaging / Web Services / application integration
> would be a better
> place if ASN.1 was the buzzword du jour, with tool vendors
> practically giving
> away sophisticated development products, marketing weasels fighting to
> get mindshare for their flavor of ASN.1-aware middleware
> products, publishers
> stuffing the shelves of Amazon and Borders with "ASN.1 for Dummies"
> "ASN.1 for Pointy Haired Bosses", "ASN.1 for Smart People",
> etc. books.
> Still, for better or worse, all this stuff is happening with XML-based
> technologies.
I am happy this stuff is happening in one way or the other. Since ASN.1
can pacifically co-exist with other XML-based technologies, it is likely
that it will be increasingly used in close relationship with XML.
Alessandro Triglia
|
