> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 21, 2004 17:58 > To: [EMAIL PROTECTED] > Cc: Alessandro Triglia; [EMAIL PROTECTED] > Subject: RE: [ASN.1] GDMO/CMIP, WSDL-XML/SOAP-XML, > FWS-ASN.1/SOAP-ASN.1 > > > > > > The ASN.1 resulting from an X.694-based mapping may be > verbose (although > > this is often due to the comments included). On the other > hand, if you > > write your schema in ASN.1 to begin with, the definitions > are usually more > > concise than the equivalent XML Schema definitions would be. > > Would this be your view, if the ASN.1 application needs to > generate XER?
Yes. In many cases, when you are writing a new ASN.1 spec that is to generate nice XML (but are not compelled to mimic special XSD features), the most common encoding instructions that you will use are ATTRIBUTE and UNTAGGED, which won't increase the size of the spec significantly. Sometimes you'll want to use NAME (to get special "case effects") or NAMESPACE, but these instructions tend to be applied collectively (in the encoding control section) and therefore don't necessarily make the spec verbose. When you are translating from XSD to ASN.1, instead, you may get a verbose ASN.1 spec sometimes. For example, if many names in the schema contain characters like underscores or non-ASCII letters, you will get a NAME instruction for each of the corresponding ASN.1 names. Also, the extensive use (in the XSD schema) of type derivation and element-substitution groups, especially in combination with element defaults and nillability, tends to produce many ASN.1 types. The positive side of this is that ASN.1 does support those XSD constructs and X.694 is able to map them. > The SOAP message structure using ASN.1 in > X.FWS is more concise than the one defined using XML! in > W3C. I agree in some cases it is true. > > How do we take existing ASN.1 application entity, convert its > SMI defined using old ASN.1 notation to a new SMI defined > using new ASN.1 notation (i.e with XER instructions)?. This > will allow the ASN.1 application entity's run-time not to > change, at least from the perspective of current users. Also > existing in-memory representation of ASN.1 values (data) may > not be altered. One may need to create a new in-memory > representation of data from which XER or BER serialization > can be performed. For all old users, BER serialization can be > performed from old in-memory representation. Does this make sense? Yes. If you are able to produce a clean ASN.1 spec (removing all old macro notation), it will be implicitly capable of generating XML encodings as well as BER/PER encodings. If you wish to make the XML nicer, say, by marking something as an attribute or by removing redundant start-tag-end-tag layers, it's easy to do that by adding XER encoding instructions. These encoding instructions will only affect the XML encodings (EXTENDED-XER), and will be ignored by other encoding rules. Alessandro Triglia OSS Nokalva > > Thanks for the response > -Manohar Naidu Ellanti > > > > Alessandro Triglia > > OSS Nokalva > > > > > > > > > > > >
