[
Lists Home |
Date Index |
Thread Index
]
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
|
