MARTY Guy wrote:
DUBUISSON Olivier wrote :
"You can use the ASN.1 schema as the central schema and encode either
in BER, DER, PER or XER (i.e., XML), or even encode in PER to
transmit on a low-bandwith channel and "decode then re-encode" in XER
for display on your PDA, for example. There are ASN.1 tools that already
allow that."
Yes, I have imaged some thing like that.
But components are XML Native or ASN.1 Native and there are a lot of ASN.1
native component. If you want data of existing ASN.1 native component to be
transmitted to an XML native component your HAVE to write the corresponding
XML Schema. The two-way translation is necessary.
Actually that is an error prone, unnecessary and wasteful step. This approach requires two schemas where one will do. It requires two validations, one per schema, for data exchange. And since both schemas are rich, there is more than one way to write a given definition in each. But depending on the which way you choose to write these definitions, and depending on the tools you use, you can greatly affect what the underlying application may be expected to handle. It will be interesting to see how good a job these schema mapping utilities actually do. Not as good as a smart human is my bet. Best if possible to stick to a single schema. And if you need to be backwards compatible with existing binary encodings, or if you need data compression and speed of processing, and if your application requires simple mechanisms to support digital signatures or encryption, or if you want to avoid the complexities of name space, XPath, XPointer, XC14N, C14N, etc. then the one schema to pick is obvious. Phil
Guy MARTY
