OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] PSVI formalization

[ Lists Home | Date Index | Thread 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 
later version.

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  


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS