[jdev] GSoC Proposal: XSD Schema Compiler

Evgeniy Khramtsov xramtsov at gmail.com
Wed Mar 26 01:07:41 CDT 2008


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.




More information about the JDev mailing list