Lists Home |
Date Index |
Robin Berjon wrote:
> Bancroft Scott wrote:
> > Robin Berjon wrote:
> >> The ASN.1 equivalent of a simple XML parser in terms of
> >> would have to properly decode (and likely handle
> negotiation for) BER,
> >> PER, CER, DER, XER, and probably LWER, OER, and SER.
> That's a bit of a
> >> behemoth to implement!
> > Not at all. While it is possible in theory to create an application
> > that uses all of BER, PER, DER, XML, etc., with very rare
> > applications use just one of these. Even in the case where
> one is using
> > an ASN.1 tool that supports all these encoding rules, an
> application would
> > select only those libraries that are needed.
> You're missing the point, the operative word being "universality". An
> XML parser can successfully read anything produced based on an XML
> schema language (not to mention all that can be done without
> any schema)
How does this prevent the use of ASN.1 for specifying schemas? If there is
no schema, there is no schema: the only option available is to use an XML
parser or write one. If you have an ASN.1 schema, you can still use an XML
parser if you wish. If you receive a PER encoding, you need to use or write
a PER decoder, but XML can be parsed by any (ASN.1 or non-ASN.1) parser.
> -- unless that schema language is ASN.1 (which could be an
> argument for
> saying it isn't exactly an XML schema language).
The various existing proposals to introduce a schema-dependent alternative
binary representation for XML (similar to the BiM) go in the opposite
direction to what you are saying here. Will XML Schema cease to be a true
"XML schema language" as soon as (and if) the W3C standardizes a
schema-dependent alternative binary representation for XML (assuming they do
so)? Certainly not. Yet, at that time, XML Schema will implicitly be
describing a binary encoding **as well as** XML 1.0, much like ASN.1
implicitly describes PER encodings as well as BER encodings as well as XML
One could argue that we already have this situation today, due to the
existence of the BiM, although the BiM is used in a limited number of
application areas and does not have the blessing of the W3C. An application
built around an XML Schema schema can use the BiM *or* XML 1.0 on the wire,
much like an application built around an ASN.1 schema can use BER *or* PER
*or* XML 1.0 on the wire.
> If all you have is an ASN.1 schema, and you're on the receiving side,
> you don't know what you're going to get.
The same is true for the BiM or whatever binary alternative the W3C will
possibly create. You don't know what you are going to get. Or better, if
you know what you are going to get in the case of the BiM, you know it in
the case of PER/BER/XML.
> If it's an ER you don't know
> about you won't read it. That just won't happen if you're
> using XML. You
> can chose to consider this unimportant, but a lot of us XML
> folks think
> it is a core asset.
So people should just drop the idea of introducing a binary alternative?
> IIRC there was a good passage in Olivier Dubuisson's ASN.1 book about
> how a decoder must know so much, unfortunately I can't find
> it right now.
> > By the way, LWER, OER and SER are not standard encoding rules of
> > ASN.1. LWER was a proposal from about a decade ago that was
> > by the submitter before being progressed. OER was created in the
> > automotive community but did not catch on. This is the
> first that I
> > am hearing about SER.
> Yes I know, which is why I set them aside in the list. SER (Specific
> Encoding Rules for signalisation) is an FT and Nokia joint spec and
> operates things like RNIS and GSM. It is not unrelated to the
> old work
> on MBER.
> Robin Berjon <firstname.lastname@example.org>
> Research Scientist, Expway http://expway.com/
> 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
> The xml-dev list is sponsored by XML.org
> <http://www.xml.org>, an initiative of OASIS
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription