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

Re: [Fwd: Re: The 11-pound solution (fwd)]


vxer define

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!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.