Re: [jdev] GSoC Proposal: XSD Schema Compiler
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.
Re: [jdev] GSoC Proposal: XSD Schema Compiler
On Sun, Mar 23, 2008 at 08:59:49PM -0600, Peter Saint-Andre wrote: All of our XML schemas are descriptive, not normative. If we really want to generate code or test in this way, we might want to create formal definitions that are normative. But I don't know if XSDs will get us there -- we might need Relax NG or Schematron or somesuch. I've been interested in that for a while now, but I haven't found the time to work on it much yet. ASN.1! ASN.1! We are tired from unvalidated XML and XSD (in those XEPs). Better to have structures which can validate himself. ermine
Re: [jdev] GSoC Proposal: XSD Schema Compiler
Dave Cridland wrote: X.694! X.694! X.694 is just a mapping XSD - ASN.1. What do you want to say?
Re: [jdev] GSoC Proposal: XSD Schema Compiler
On Wed Mar 26 11:48:32 2008, Evgeniy Khramtsov wrote: Dave Cridland wrote: X.694! X.694! X.694 is just a mapping XSD - ASN.1. What do you want to say? Exactly. So given XSD, you have ASN.1. In which case, it should become apparent that there's nothing particularly magical about ASN.1 - it's not self-validating, as such. Sure it'd be nice to have normative schemas, but ASN.1 isn't anything to do with this. Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [jdev] GSoC Proposal: XSD Schema Compiler
On Wed Mar 26 11:10:13 2008, Anastasia Gornostaeva wrote: ASN.1! ASN.1! X.694! X.694! (With help from Kev, who inadvertantly pasted most of X.693 into jdev to help remind me which X.69Y it was.) Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [jdev] GSoC Proposal: XSD Schema Compiler
Dave Cridland wrote: X.694 is just a mapping XSD - ASN.1. What do you want to say? Exactly. So given XSD, you have ASN.1. In which case, it should become apparent that there's nothing particularly magical about ASN.1 - it's not self-validating, as such. Sure it'd be nice to have normative schemas, but ASN.1 isn't anything to do with this. Dave. Could you show me an xml decoder which performs parsing and validation at the same time (like ASN.1 decoder does)?
Re: [jdev] GSoC Proposal: XSD Schema Compiler
On Wed, Mar 26, 2008 at 08:48:32PM +0900, Evgeniy Khramtsov wrote: Dave Cridland wrote: X.694! X.694! X.694 is just a mapping XSD - ASN.1. What do you want to say? Only xsd - asn.1, not xsd - asn.1. Right? ermine
Re: [jdev] GSoC Proposal: XSD Schema Compiler
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. Regards, Gerhard On 24/03/2008, at 4:32 PM, Evgeniy Khramtsov wrote: Remko Tronçon wrote: Does anyone have any experience/thoughts on this? I have a thought: you (along with EXI WG) are just reinventing ASN. 1. Of course, I know we cannot swith to ASN.1, so we have to reinvent a wheel. It's sad.
Re: [jdev] GSoC Proposal: XSD Schema Compiler
Remko Tronçon wrote: Does anyone have any experience/thoughts on this? I have a thought: you (along with EXI WG) are just reinventing ASN.1. Of course, I know we cannot swith to ASN.1, so we have to reinvent a wheel. It's sad.
Re: [jdev] GSoC Proposal: XSD Schema Compiler
On Sat, Mar 22, 2008 at 01:08:21PM +0100, Remko Tronçon wrote: I added another proposal to the GSoC page, entitled XSD Schema Compiler. Sounds interesting. And probably useful, too. -- Maciek Niedzielski xmpp:[EMAIL PROTECTED]
Re: [jdev] GSoC Proposal: XSD Schema Compiler
IMHO, not sure what the input will be to such parser, different XMPP libraries will likely use different xml parsing techniques/representations like DOM,SAX,PULL-Parsing,DOM4J,to name a few of them. cheers, pablo --- Remko Tronçon [EMAIL PROTECTED] escribió: Hi, I added another proposal to the GSoC page, entitled XSD Schema Compiler. Here is a short description: The most boring, time-consuming, and error-prone job of an XMPP client developer is writing code to parse XML stanzas, and turning them into datastructures to be used by the rest of the code. The code generated is often a lot of copy-paste work, and is sensitive to very subtle bugs. In this project, the student will solve this problem once and for all, by building a compiler that turns the XSD schemas that define the stanzas into a combination of simple datastructure classes, the parser that turns xml into these generated classes, and the code to turn these datastructures into xml back again. The XSD Compiler should be modular enough to allow plugging in backends for different target languages (C++/STL, C++/Qt, Python, ...). However, the student will initially focus on one backend, and may extend this to different backends if time allows it. A project like this has a reach far out of the XMPP community, to any project that uses XML documents standardized by an XSD. However, the project will (initally) focus only on the XSD defined by the XSF, and making sure that (almost) all XSD's can be compiled into code. Does anyone have any experience/thoughts on this? cheers, Remko Tarjeta de crédito Yahoo! de Banco Supervielle. Solicitá tu nueva Tarjeta de crédito. De tu PC directo a tu casa. www.tuprimeratarjeta.com.ar
Re: [jdev] GSoC Proposal: XSD Schema Compiler
The RFC/XEP specs would be half of the input. The other half would be a template per-language/parsing technique. The second part would be the pluggable section that Remko refers to. As a matter of interest there is an XSD to c#/vb complier provided by MS for .Net. I think that there are one or two community efforts to write compatible implementations that extend on what MS outputs - better supporting collections, etc. I haven't looked, but there must be other XSD schema compilers. It would be interesting to see one dedicated to the generation of XMPP objects, but it would need to be very flexible to handle all the different languages and frameworks out there. On Sun, Mar 23, 2008 at 7:14 PM, Pablo Polvorin [EMAIL PROTECTED] wrote: IMHO, not sure what the input will be to such parser, different XMPP libraries will likely use different xml parsing techniques/representations like DOM,SAX,PULL-Parsing,DOM4J,to name a few of them. cheers, pablo --- Remko Tronçon [EMAIL PROTECTED] escribió: Hi, I added another proposal to the GSoC page, entitled XSD Schema Compiler. Here is a short description: The most boring, time-consuming, and error-prone job of an XMPP client developer is writing code to parse XML stanzas, and turning them into datastructures to be used by the rest of the code. The code generated is often a lot of copy-paste work, and is sensitive to very subtle bugs. In this project, the student will solve this problem once and for all, by building a compiler that turns the XSD schemas that define the stanzas into a combination of simple datastructure classes, the parser that turns xml into these generated classes, and the code to turn these datastructures into xml back again. The XSD Compiler should be modular enough to allow plugging in backends for different target languages (C++/STL, C++/Qt, Python, ...). However, the student will initially focus on one backend, and may extend this to different backends if time allows it. A project like this has a reach far out of the XMPP community, to any project that uses XML documents standardized by an XSD. However, the project will (initally) focus only on the XSD defined by the XSF, and making sure that (almost) all XSD's can be compiled into code. Does anyone have any experience/thoughts on this? cheers, Remko Tarjeta de crédito Yahoo! de Banco Supervielle. Solicitá tu nueva Tarjeta de crédito. De tu PC directo a tu casa. www.tuprimeratarjeta.com.ar -- - Norman Rasmussen - Email: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/
Re: [jdev] GSoC Proposal: XSD Schema Compiler
I haven't looked, but there must be other XSD schema compilers. It would be interesting to see one dedicated to the generation of XMPP objects, but it would need to be very flexible to handle all the different languages and frameworks out there. The biggest problem I foresee is that we have a lot of 'any namespace' children in our schemas. (e.g., Jingle 'content' elements in practice only have 'transport' and 'description' children, but the xsd says that it can have any child). Although this is not a major problem i guess, if the generated datastructures provide facilities for the client to easily retrieve specific children. I think i'm going to sit on this one a little longer before turning it into a GSoC. However, I think that, if done correctly, this could be extremely useful (and save a lot of work). cheers, Remko
Re: [jdev] GSoC Proposal: XSD Schema Compiler
Remko Tronçon wrote: Hi, I added another proposal to the GSoC page, entitled XSD Schema Compiler. Here is a short description: The most boring, time-consuming, and error-prone job of an XMPP client developer is writing code to parse XML stanzas, and turning them into datastructures to be used by the rest of the code. The code generated is often a lot of copy-paste work, and is sensitive to very subtle bugs. In this project, the student will solve this problem once and for all, by building a compiler that turns the XSD schemas that define the stanzas into a combination of simple datastructure classes, the parser that turns xml into these generated classes, and the code to turn these datastructures into xml back again. The XSD Compiler should be modular enough to allow plugging in backends for different target languages (C++/STL, C++/Qt, Python, ...). However, the student will initially focus on one backend, and may extend this to different backends if time allows it. A project like this has a reach far out of the XMPP community, to any project that uses XML documents standardized by an XSD. However, the project will (initally) focus only on the XSD defined by the XSF, and making sure that (almost) all XSD's can be compiled into code. Does anyone have any experience/thoughts on this? All of our XML schemas are descriptive, not normative. If we really want to generate code or test in this way, we might want to create formal definitions that are normative. But I don't know if XSDs will get us there -- we might need Relax NG or Schematron or somesuch. I've been interested in that for a while now, but I haven't found the time to work on it much yet. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
[jdev] GSoC Proposal: XSD Schema Compiler
Hi, I added another proposal to the GSoC page, entitled XSD Schema Compiler. Here is a short description: The most boring, time-consuming, and error-prone job of an XMPP client developer is writing code to parse XML stanzas, and turning them into datastructures to be used by the rest of the code. The code generated is often a lot of copy-paste work, and is sensitive to very subtle bugs. In this project, the student will solve this problem once and for all, by building a compiler that turns the XSD schemas that define the stanzas into a combination of simple datastructure classes, the parser that turns xml into these generated classes, and the code to turn these datastructures into xml back again. The XSD Compiler should be modular enough to allow plugging in backends for different target languages (C++/STL, C++/Qt, Python, ...). However, the student will initially focus on one backend, and may extend this to different backends if time allows it. A project like this has a reach far out of the XMPP community, to any project that uses XML documents standardized by an XSD. However, the project will (initally) focus only on the XSD defined by the XSF, and making sure that (almost) all XSD's can be compiled into code. Does anyone have any experience/thoughts on this? cheers, Remko
