[
Lists Home |
Date Index |
Thread Index
]
> -----Original Message-----
> From: Alessandro Triglia [mailto:sandro@mclink.it]
> Sent: Monday, April 19, 2004 00:53
> To: 'Bullard, Claude L (Len)'; 'XML DEV'
> Subject: RE: [xml-dev] Validation vs performance - was Re:
> [xml-dev] Fast text output from SAX?
>
>
>
>
> > -----Original Message-----
> > From: Bullard, Claude L (Len) [mailto:clbullar@ingr.com]
> > Sent: Sunday, April 18, 2004 14:49
> > To: 'Michael Champion'; 'XML DEV'
> > Subject: RE: [xml-dev] Validation vs performance - was Re:
> > [xml-dev] Fast text output from SAX?
> >
> >
> > Yes. Dead on. When where and under what conditions
> > do applications need alternative formats? Those
> > who think they need one should be making the cases
> > for those conditions now.
> >
> > Here's the shakedown: binaries vs text formats as
> > Bob W. points out is an old debate. There are:
> >
> > 1. Those who are developing a generalized binary
> > and want to offer that.
>
>
> Let me point out one fact about ASN.1 that I see overlooked sometimes,
> especially when people try to compare ASN.1 with XML: **ASN.1 is not
> inherently binary**.
>
> ASN.1 focuses on a level of data description that is more
> abstract than a
> wire representation. (This is one reason why a direct
> comparison with XML
> 1.x syntax is difficult or even inappropriate.)
>
> For example, the following ASN.1 type definition:
>
> ------------------------------------------
> EmailMessage ::= SEQUENCE {
> from EmailAddress,
> to SEQUENCE OF address EmailAddress,
> cc SEQUENCE OF address EmailAddress,
> sent DATE-TIME,
> received DATE-TIME,
> subject UTF8String,
> body UTF8String
> }
>
> EmailAddress ::= UTF8String (PATTERN "(some pattern)")
> ------------------------------------------
>
> is a complete description of data (from ASN.1's point of
> view), but says
> nothing at all about the on-the-wire representation of the data.
>
> In particular, there is no implication that the data will be
> represented in
> some binary form. The on-the-wire representation can be XML
> 1.0 just as
> well.
>
> ASN.1 folks call the data-description level "type definition"
> or "abstract
> syntax", and call the on-the-wire representation "encoding"
> or "transfer
> syntax". The main focus being on the "abstract syntax"
> enables multiple
> distinct "encoding rules" to exist, each specifying a
> different on-the-wire
> representation of the data that has been defined at the
> "abstract syntax"
> level.
>
> This has given rise, over the years, to a number of standard "encoding
> rules", some of which are binary, some of which use XML 1.0.
> Every time,
> there has been a good reason for standardizing a new set of
> encoding rules,
> starting from BER, then DER/CER, then PER, then XER, then
> EXTENDED-XER.
>
> I am not saying that the ASN.1 solution fits all cases (or
> even most of the
> cases). I know that many people prefer thinking in terms of
> bits-on-the-wire (or in terms of Unicode characters to be
> encoded in some
> character-encoding before being placed on the wire), and I am not
> questioning their views here.
>
> However, I suspect that many applications are being built
> around a schema
> (now often XML Schema) in such a way that they will not tolerate any
> variations to the form of XML document that does not conform
> to the schema.
>
>
> If my suspect is well-founded,
Oops! I meant "suspicion".
Alessandro
> then these applications could
> be built as
> easily around a schema written in ASN.1. ASN.1 fits a common
> definition of
> a schema language, in that it "offers facilities for describing the
> structure and constraining the contents of XML 1.0 documents,
> including
> those which exploit the XML Namespace facility".
|
