Currently I am looking for a more compact format for information card .crd files.
Because I am working in a telco environment for 10 years now ASN.1 comes to (my) mind.
So I tried to feed identity.xsd to an xsd-to-ASN.1 translator.
First by uploading just the identity.xsd file. -> no luck here.
The translator does not revolve the urls of the required other schema definitions.
- identity.xsd
- oasis-200401-wss-wssecurity-secext-1.0.xsd
- oasis-200401-wss-wssecurity-utility-1.0.xsd
- ws-addr.xsd (www.w3.org/2006/03/)
- ws-policy.xsd
- ws-trust.xsd
- xenc-schema.xsd
- xmldsig-core-schema.xsd
Because of this I put all these files into one zip archive and upload it to the translator.
Again, no luck. There are conflicting definitions for wsa (schemas.xmlsoap.org/ws/2004/08/) in identity.xsd and ws-trust.xsd and the translator does not like that. Don't know whether this is an error in the ws-trust or identity schema definitions... Mike is checking on this. I am sure he knows (as always) the right person to answer information card deep-dive questions. Maybe the translator has an error?
To produce information card ASN.1 I tweaked ws-trust.xsd to use the same definition for wsa as identity.xsd. This time the translator likes the input and produces ASN.1 files. These are not for the faint of heart. But actually no human wants to read ASN.1, right?!
Next step: Feed the ASN.1 files into an asn1 to java compiler/translator.
OSS Nokalva has a nice trial version for this task.
I produced a bunch of java classes which nearly all compile nicely. There is one small glitch with xs:unsigned_long's max value but this is easy to fix.
Why am I doing this? Because I am working on information card support on mobile phones and network speed and computing power in this area are not funny. Have to see where this ASN.1 road leads to... Probably to nowhere because the midlet size exploded after integrating the generated java files. And the obfuscator (ProGuard 4.1) blew up too. So back to square one...
No comments:
Post a Comment