[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Validation vs performance - was Re: Fast text ou
> -----Original Message----- > From: Alessandro Triglia [mailto:sandro@m...] > Sent: Monday, April 19, 2004 00:53 > To: 'Bullard, Claude L (Len)'; 'XML DEV' > Subject: RE: Validation vs performance - was Re: > Fast text output from SAX? > > > > > > -----Original Message----- > > From: Bullard, Claude L (Len) [mailto:clbullar@i...] > > Sent: Sunday, April 18, 2004 14:49 > > To: 'Michael Champion'; 'XML DEV' > > Subject: RE: Validation vs performance - was Re: > > 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".
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|