OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xml-dev] Notation processors



On Mon, 22 Oct 2001, Bent Rasmussen wrote:

> There are a lot of binary languages out there. I wonder, how can one
> translate these into XML languages in the easiest possible way, without
> having to program a module to perform the translation every time a new
> binary language appears. The solution I think, is to build something similar
> to an XSLT processor. Something which uses a translation specification for
> each binary language.

This is nearly in place already :-)

First, some history.

The problem of extensible data interchange between heterogenous systems,
that XML aims to solve, arose many years ago. Indeed, it's about as old as
platform independent networking itself.

The biggest result of that original work were the ASN.1 notation for
abstract types (eg, "A person record contains a name which is a string and
an address which is a string as well"), and a series of encodings that map
those types into actual patterns of bits.

Two things make this particularly relevant.

1) A technology called ECN is in the final stages of standardisation,
which allows "one off" encodings of ASN.1 abstract types into bit strings.
Whereas the ASN.1 encoding rules work for any arbitrary ASN.1 abstract
type, an encoding written in ECN is specific to one type only. It is
designed to bridge between legacy binary encodings and the world of ASN.1
abstract types. For example, the IPv4 header format might be defined in
terms of the data it contains as an ASN.1 abstract type, then ECN written
to map that to the actual bit sequences that make for valid IPv4 packet
headers. Therefore, ASN.1 abstract values can be mapped to arbitrary
binary formats.

2) A set of encoding rules for ASN.1 values as XML is being devised, which
will again unify the XML and ASN.1 data models into an interoperable
whole. XML isn't expressive enough to do everything ASN.1 does, but the
good news is that ASN.1 is expressive enough to transport XML data with no
loss of information because of this :-)

So in other words, when ECN and the XML encoding rules are both defined,
then there will be a path between random binary data and DOM trees. Is
that good enough?

ABS

-- 
                               Alaric B. Snell
 http://www.alaric-snell.com/  http://RFC.net/  http://www.warhead.org.uk/
   Any sufficiently advanced technology can be emulated in software