Gerhard Weis wrote:

Hi,

as you mention ASN.1 and XML.
I did some research recently about it, and I found a standard 1:1 mapping for ASN.1 and XML-Schema, and there is also a ASN.1 encoding standard (extended XER or something like that) which ensures, that a structure serialized to XML
is valid according to the equivalent XML-Schema.

By using these two standards, it should be no problem to switch to ASN. 1 and vice verse.

You are right, partially :)
Yes, there is XSD <-> ASN.1 mapping (and even automated tools exist). Yes, there is XER encoding (however, I didn't see any open source XER-compilers). But that doesn't solve the problem. The main logical steps in XMPP implementations are:
1. Getting an XML stream.
2. Decoding it. Getting the internal *unvalidated* structure.
3. Validating that structure (the most boring step). Getting ready to use *valid* structure.
4. Safely fetching values from the *valid* structure.

And here are the steps in the case of ASN.1:
1. Getting an ASN.1 stream (BER, PER, XER, etc.).
2. Decoding it. Getting the internal *validated* (!!!) structure.
3. Safely fetching values from the *valid* structure.

The first problem: the structure provided by ASN-compilers is not equal to the structure used in existing implementation. We need code replacing or structure converting in this case.

The second and the main problem which occurs even with the XSD-validators: the steps 3 and 4 are mixed up together. Here is an example:

if (unvalidated_structure has mandatory_node) {
   mandatory_value = get_node_value(mandatory_node);
} else {
   damn_what_should_i_do_here();
   need_to_ask_a_stupid_question_in_JIG();
}

In this case we have to rewrite all this ugly code.
Also, I'd like to note about ASN.1 benefits: even if we use XSD-validators, we cannot get rid of step 3. We just can automate it. Thus, ASN.1 implementation is faster in general.

Reply via email to