> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Manohar Naidu Ellanti > Sent: Tuesday, April 20, 2004 09:58 > To: [EMAIL PROTECTED] > Subject: [ASN.1] GDMO/CMIP, WSDL-XML/SOAP-XML, FWS-ASN.1/SOAP-ASN.1 > > > I would like to request opinions on how to map (if ever there > would be need) GDMO/CMIP models to WSDL-XML/SOAP-XML or > FWS-ASN.1/SOAP-ASN.1? Also, I have few questions with respect > to some of the XML<-->ASN.1 and FWS efforts: > > Currently there is vast amount of GDMO/ASN.1 specifications > (M.3100,G.774 etc). So my thought is that GDMO will continue > to be around. I can send a figure that I drew to map GDMO to > WSDL(+schema) to any one interested (please mail me > seperately). But behind the plethora of information available > in X.693,x.694,x.FWS I find it difficult to come to some > elementary understanding of how GDMO/CMIP to fGDMO(fast GDMO) > will look like. Your help will be greatly appreciated. a > comment on the GDMO part of the above Mr Thorpe > > [Thorpe] Please note, however, that GDMO is considered > obsolete since the introduction of Information Object Classes > to ASN.1. See additional comments below. > > Are there any tools to convert legacy GDMO models to FWS (or > XML). Also, I believe all newer ITU-T specs, such as for > FTTP/PON, are being developed using UML. Is this correct?
The ITU-T plans to develop a Recommendation on a UML profile for ASN.1. However, real work has yet to begin. Also, it is not yet clear if the Recommendation will specify (stricty) a UML profile, or (more broadly) a limited mapping of class diagrams to ASN.1, or both things at the same time. A standard UML profile would enable a human modeler to use a UML tool for creating or visualizing ASN.1 type definitions in UML (as extended/specialized by the profile). The actual ASN.1 notation would be in the background and would not necessarily be visible to the user. The UML profile could be used to create either the "data" part of a UML model (of any complexity) or a free-standing data model. This can be helpful to people who are expert modelers but don't know ASN.1, or even to people who know neither ASN.1 nor UML well, but may be able to grasp the basic meaning of a class diagram shown on a printed page or on the screen. (I know that several people are using this method with XML Schema, and there are tools that explicitly support this, so there is no reason why people could not do the same with ASN.1.) A (limited) standard mapping of UML class diagrams to ASN.1, instead, would enable a much broader range of class diagrams to be converted to ASN.1. The human modelers would not need to use a UML profile and learn its rules and its semantics, in order to create a class diagram that is mappable to ASN.1. (However, the use of a profile would likely provide much finer control over the ASN.1 generated, for those who need it.) I gave a presentation on this subject at an ITU-T workshop recently. See http://www.itu.int/ITU-T/worksem/uml/presentations/uml-0304-triglia.zip (The presentation does not address the broader issue of specifying a mapping vs. specifying a profile. It only gives suggestions on how to model certain ASN.1 constructs in UML. Those suggestions could be incorporated in a UML profile for ASN.1.) > If > so how is FWS (ASN.1 schema notation) going to fit with UML approah? FWS depends on other existing web-services specifications. In the most common scenarios, the datatype definitions will be originally specified in XML Schema, and translated to ASN.1 using X.694. UML would not help here, as there is no modeling to be done within the scope of FWS, but only automatic translation. (UML may have been used in the big picture of service design, but this does not affect FWS.) However, in a broader scenario (which should become prevalent in 1-2 years, depending on the availability and success of WSDL 2.0), it will be possible to use ASN.1 directly in service descriptions. In this case, a UML profile for ASN.1 could help. > > Overall, I wish there are more figures in X.fws and X.694 > that depict the architecture and use cases before the > translation rules or information items. The two figures in > X.694(the draft X.694, not the final doc) do help - and > > Particularly, figure 1 in X.694 - there is lot of conversion > from XML document to ASN.1 purely for the purpose of > encoding. It seems to me that this is too much of processing > by the device - probably will make sense if the final encoded > data is to be transferred on a bandwidth limited connection. > But would it make sense for HPC to bother with this > conversion? - one response I got from Mr Thorpe: > > [Thorpe]Please note that the conversion from XSD to ASN.1 is > not necessarily intended to be done on the device. A tool > (such as one created by OSS > Nokalva) can read the XSD schema once (the compiler) and > generate control information that just knows how to > encode/decode the messages in either XML or BER, or PER etc. > with the same static control information. There is no need > for the device to do the X.694 translation on the fly. > > Next, in figure 2 - first sending schema using ASN.1 > (+encoding) followed by sending instance document using > ASN.1(+encoding) - seems little odd. In legacy WSDL/SOAP , > isn't the receiver expected to feed the schema to the XML parser? > > In either case, both figures seem to imply that the server > and client applications still use XML (DOM/SAXP) - it is only > for the purpose of using ASN.1's efficient encoders - BER/PER > etc that the conversion from XML to ASN.1 and vice versa is > done. Is my understanding correct? > > Also, would XER (XML Encoding for ASN.1) then not be relavent > for FWS? I did get some response from Mr Thorpe and Mr Leg for this: > > [slegg] XER is relevant for FWS implementations that use an > ASN.1 compiler rather than DOM or SAX. If there is a need to > interwork with a client or server that is not enabled for FWS > then an XER encoder can be used to produce the XML > representation of a document. > > [Thorpe] WS would use one of the binary encoding rules of > ASN.1, but a Web Service should fall back to use of XML if > its peer does not understand the compact binary FWS > encodings. Finally - ASN.1 schema notation for XML - I think > it looks quite verbose and difficult to read compared to XML > schema. Do you think my view is reflective of some others ? > If so, any comments? 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. Alessandro Triglia OSS Nokalva >
