[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: [Fwd: Re: The 11-pound solution (fwd)]
Hi Alessandro! On Saturday 14 September 2002 9:08 pm, Rich Salz wrote: > > the application. On the other hand, ASN.1 modules are produced by human > > beings, published in standards or other such, and used by the > > implementers of these standards. > > I think that is no different, say, than any of the XML Schema languages. In terms of the goals fulfilled, sure. > People concerned with the "verbose" XML serialization should look at DER > or PER for lessons to be learned and avoided. Why DER? PER was designed to placate the people who found BER too 'verbose', so it is a pretty extreme example of terseness, hell bent to save every bit. Then again, it was then found that all the effort occured once when the encoder was generated, meaning that PER codecs are faster at runtime than BER codecs, which is useful in itself :-) > > ASN.1 with VXER is a powerful XML schema definition language. > > Outside of its use as a legacy migration tool, what does it offer to XML > developers that existing schema languages do not have? ASN.1's a lot more expressive... if all you need is to declare that a Person consists of a Name string and so on there's no great win over any other schema language that has a reasonable syntax (as opposed to XSD...). But if you want to define something like SOAP, then ASN.1 has a few neat features picked up over *decades* of defining protocol wrappers, such as Information Object Classes... IOCs let you specify table-driven constraints, and let others expand that table for their application. You can use this to make something like an XML namespace declaration; at a point where something of truly arbitrary type can occur, you use an OID and an ANY that is constrained to be of the type of the OID. Now, map 'OID' to 'namespace URI' and 'ANY' to 'element' and 'constrained to be of the type of the' to 'from within the namespace of' and you have the equivelant XML thing, where you embed stuff from other namespaces in those contexts. Except that it doesn't have all the issues about namespaces :-) The OID specifies a type, and the schema for that value specifies that there's a type and a thing of that type. You can also specify things like RPC protocols; you can define two messages, 'Request' and 'Response'. Request contains the ID of the procedure to invoke on the server, and a list of arguments whose type is constrained purely by the declaration that they be of the types declared for that procedure ID; likewise Response contains an embedded return value of suitable type or exception code of suitable type. The RPC protocol doesn't specify the table mapping procedure IDs to types and so on; that's supplied in each module that uses the RPC protocol module as a base to define an actual RPC protocol. So what does this gain you? You can express more of your types and the relationships between them. You don't need to resort to an 'any' type with a comment noting that it had better fulfill some rules written in English. Not only does this save on translation costs and problems when foreigners implement the spec, it means you can generate more code automatically and have more potential mistakes detected automatically by software :-) > > The ITU-T and ISO JTC 1 are also developing a recommendation (X.694) > > which provides a full mapping from XML Schema into ASN.1 + VXER. > > That seems silly. XSD->ASN1->XML serialization. Or did I misunderstand? That would seem odd if done as one operation, but one might have some existing XSD schema for something useful that you want to introduce into an ASN.1 system. So map the schema to ASN.1 to fit in with the abstract value model, and write your code in terms of that model, but tell the system to use XML to serialise those abstract values for transfer. > XSD->ASN1->DER might be interesting. Yep! But more likely BER or PER - CER and DER are used for more specialist stuff with cryptography. "If you can't understand the difference between CER and DER you shouldn't be using either" :-) > > Among other things, this allows exploiting the binary > > encoding rules of ASN.1 to save bandwidth and CPU cycles wherever this > > makes sense. > > They they're not the same XML document. > > I guess I'm confused. I'm confused by your last statement :-) I guess the first word is meant to be "Then", but still, what's not the same as what? Or am I missing some other context? Wouldn't be the first time :-) > /r$ ABS -- Oh, pilot of the storm who leaves no trace, Like thoughts inside a dream Heed the path that led me to that place, Yellow desert screen
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|