[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: ASN.1 is an XML Schema Language (Fix those lists!) and Bin

  • To: "'bob@w...'" <bob@w...>
  • Subject: RE: ASN.1 is an XML Schema Language (Fix those lists!) and Binary XML not needed...
  • From: "Bullard, Claude L (Len)" <clbullar@i...>
  • Date: Mon, 3 Nov 2003 16:47:07 -0600
  • Cc: xml-dev@l...

asn.2 api
You are the expert.  I accept that what you say is so. 
On the other hand, if someone gets in there and implements 
all of their application with 20% of ASN.1, what pieces 
would they be leaving out and can they still call it an 
ASN.1 app.  Can they cut their costs and still conform and 

A big problem with SGML was that the spec normatively tied 
together pieces that should have been optional.  XML made 
them optional and got rid of the encoding dilemmas for the 
most part.  Think of it as having beautiful flowers that 
grow behind thickets of brambles.  The risk in removing 
the brambles is that it may cause the flowers to die. If 
as you say, all the weeding has been done and the customers 
are happy with that, then you have no problem.  On the other 
hand, the empirical observations are that uptake of ASN.1 at 
the scale of XML, HTML, etc. has not been fast.  Why?

Maybe the 'range' is too broad.  Dunno.

I predicted that people would fight to put some features 
of SGML back, particularly the SGML Declaration and the 
features that enabled one to cut back on the size of the 
file (eg, minimization).  So far, we see occasional noises 
like that, but they are always met with alternative solutions 
(eg, binaries, the entity flaps, alternate syntaxes) but 
none of these has made a dent in XML 1.0.  One reason for 
that is precisely that the scale of fielded apps is so large 
now.  There is power in numbers, but also some constraints.


-----Original Message-----
From: Bob Wyman [mailto:bob@w...]

Claude L Bullard wrote:
> If you decide to subset ASN.1, you will need a 
> considerable amount of fortitude.  You may even 
> have to give away the credit.  Be sure to keep 
> ALL the documentation to fight the patent predators.
	Why would we subset ASN.1? The worst "excesses" in its
definition were removed almost a decade ago when macros were trashed.
What is there in ASN.1 that you would take out today? As it stands,
everything that is in there is being used by someone and given that
ASN.1 is used to drive our cell phone system, much of the security
world (certificates), LDAP, SNMP, etc. it is unlikely that you'll find
bits that can be removed without causing extreme pain in some very
sensitive place. If you take things out, you'll just be bifurcating
the world again. You'll have ASN.1 people fighting to get features put
back into ASN.2 and you'll have people enhancing ASN.2 to include
things already handled well by ASN.1. Not good.
	You haven't made it clear what would be gained by subsetting
ASN.1. What does ASN.1 have that ASN.2 shouldn't have? In order to
have enough richness of expression to permit the broad range of XML to
be described, ASN.1 needs a fairly large percentage of its current

		bob wyman


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.