[
Lists Home |
Date Index |
Thread Index
]
> -----Original Message-----
> From: Tahir Hashmi [mailto:code_martial@softhome.net]
> Sent: Wednesday, February 05, 2003 01:15
> To: xml-dev@lists.xml.org
> Subject: Re: [xml-dev] Xqueeze: Compact XML Alternative
>
>
> On Tue, 04 Feb 2003 09:07:20 -0500
> Chiusano Joseph wrote:
>
> > Would you have a sense of how this binary representation
> comparse with
> > that of ASN.1 [1]?
>
> ASN.1 is, from what I gather, a method of specifying data
> formats in communication protocols and there are facilities
> for interconversion between ASN.1 and XML but I'm not sure
> whether one can generate SAX events or construct a DOM tree
> directly from an ASN.1 format document.
No one that I am aware of is doing that, but this is possible in
principle. From the ASN.1 point of view, an XML document is seen as an
encoding of an "abstract value", whose "type" is defined in ASN.1
notation. The same "abstract value" can also be encoded in binary form
using any of the standard binary encoding rules of ASN.1, namely BER,
DER, and PER. In other words, in ASN.1 one defines "types", and the
values of these types are encoded either in XML or in binary form.
This means that any binary-encoded value can be automatically converted
to an XML-encoded value and vice versa, provided that an ASN.1 type
definition for the value is available (and, of course, provided that the
binary-encoded or XML-encoded value is a valid encoding as per the ASN.1
standards).
The current standard "XML encoding rules" can only produce very simple
classes of XML documents. However, the forthcoming "extended XML
encoding rules" standard - an Amendment to ITU-T X.693 - will support a
much wider range of classes of XML documents, comparable with what can
be described by using XML Schema.
> They say that no tree
> information is stored in the binary encoding[2].
>
> Apparently, you can generate an ASN.1 binary encoding for
> your language specification and there are tools that will
> generate parsers in several languages for that format[3]. The
> problem here is that you'd have to modifiy your parser every
> time you make changes to your specification. This is a major
> headache, IMHO, since you'll have to bundle a parser with
> your applications and off-the-shelf parsers would be unusable.
I am not sure your description is correct. I would say that many common
ASN.1 tools process the ASN.1 type definitions and automatically
generate java classes or C++ classes or C structures, which the
application developers manipulate in order to build messages to be sent
or in order to access the contents of received messages.
Alessandro Triglia
OSS Nokalva
>
> With Xqueeze, all that you need to port an existing XML-based
> application to xqML based one is an off-the-shelf xqML parser
> at the consumer end and an xqML generator at the source end.
> [On this thought, is there a standard API for generating XML
> documents? I have implemented counterparts of some of expat's
> API for XML. I also was suggested to implement API for
> generating xqML from a given DOM tree but I haven't done that yet.]
>
> Please correct me if I have misunderstood some or all of this.
>
> > [1] http://asn1.elibel.tm.fr/xml/
> [2] http://asn1.elibel.tm.fr/xml/benefits.htm
> [3] http://asn1.elibel.tm.fr/links/#tools
>
> --
> Tahir Hashmi (VSE, NCST)
> http://staff.ncst.ernet.in/tahir
> tahir AT ncst DOT ernet DOT in
>
> We, the rest of humanity, wish GNU luck and Godspeed
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org
> <http://www.xml.org>, an initiative of OASIS
<http://www.oasis-open.org>
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>
|
