Lists Home |
Date Index |
On Friday 10 May 2002 13:50, you wrote:
> Hi, Al, knew we could get you to join in!.
Rattle my cage :-)
> > It is more accurate to compare ASN.1 to XML schema languages and XML to
> > BER/PER/CER/DER than to compare ASN.1 to XML, by the way.
> Yes, and that's why I mentioned it in the context of PVSI information,
> which is so closely related to schema information. PVSI data in PER?
Could be done... you can write an ASN.1 schema for anything, even the PSVI...
but do we really want to be passing around PSVIs? To enable information
transfer (as opposed to data transfer) without everyone needing schemas? Or
as an intermediate format in a tightly-bound pipeline to push all the schema
stuff to the very beginning of the pipeline?
BER, CER, and DER (CER and DER are just variants of BER with some specialised
constraints, at the cost of ease and efficiency of implementation, for doing
digital signature stuff) are all kind of PSVI-esque.
A BER message encodes a value as a flag saying what type it is, the length,
then the value itself. That type flag is PSVI-esque?
That type information is not generally necessary for decoding, except that
when you have a place where various different types of values can go it is
used to select the alternative, so just removing it *does* break things
unless you replace it with a selector code in places. This is part of what
PER - the packed encoding rules - does, although it is very careful not to do
it in such a way that breaks extensibility, since BER decoders can skip
unknown element types in a sequence when reading something produced by a
That reminds me... extensibility. In the XML world, the 'extensible' really
just means 'you can define your own vocabularies'. There's no explicit
support for different versions of vocabularies to try to interact beyond what
is intrinsically provided by having tagged values that can be skipped if
unknown like in BER. ASN.1 has an explicit versioning mechanism for revisions
of schemas that allows one to control the interoperability between them,
explicitly marking the changes so processors can deal with different versions
Is this a requirement XML schema languages other than ASN.1 are going to
stumble into in a few year's time and make XML-DEV writhe with curses and
> Tom P
Alaric B. Snell
http://www.alaric-snell.com/ http://RFC.net/ http://www.warhead.org.uk/
Any sufficiently advanced technology can be emulated in software