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

Re: PSVI formalization

• To: "Thomas B. Passin" <tpassin@c...>,xml-dev@l...
• Subject: Re: PSVI formalization
• From: Alaric Snell <alaric@a...>
• Date: Fri, 10 May 2002 14:05:27 +0100
• In-reply-to: <002001c1f821$357b8060$0bf13044@tbp>
• References: <000b01c1f786$4c628d50$887ba8c0@mitchum> <E1765zz-0005WZ-00@c...> <002001c1f821$357b8060$0bf13044@tbp>

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 
well.

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 
debates?

>
> Tom P
>

ABS

-- 
                               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  

• Follow-Ups:
  • Re: PSVI formalization
    • From: "Rick Jelliffe" <ricko@a...>

• References:
  • RE: PSVI formalization
    • From: Bill de hÓra <dehora@e...>
  • Re: PSVI formalization
    • From: Alaric Snell <alaric@a...>
  • Re: PSVI formalization
    • From: "Thomas B. Passin" <tpassin@c...>

• Prev by Date: Re: XPath 2.0 - how much of XQuery should it include?
• Next by Date: RE: PSVI formalization
• Previous by thread: Re: PSVI formalization
• Next by thread: Re: PSVI formalization
• Index(es):
  • Date
  • Thread