Lists Home |
Date Index |
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.
From: Bob Wyman [mailto:email@example.com]
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