+1 from me damitha
On Fri, 2004-12-31 at 17:03, John Hawkins wrote: > > +1 for enum ordering - good point ! > > John Hawkins > > > > Samisa Abeysinghe <[EMAIL PROTECTED]> wrote on 31/12/2004 > 02:07:54: > > > +1 from me too. > > > > Looking into memory leaks for the past few days, I got the feeling > > that handling of types are somewhat spread across the code. > > As an example, please have a look at src/common/Param.h header. > > There are two classes here and basically, they are meant to handle > > types. (see ParamValue class) > > Would be much easy if we could centralize handling of types. > > > > Re:should we be supporting all 44 built-in simple types? > > I think yes. However, may require some effort, including WSDL2Ws tool > fixes. > > I also suggest that we consider simple things as the oder of type > > declarations in enums etc (e.g. XSDTYPETag in > > include/axis/TypeMapping.hpp). I propose we have the same ordering as > > in the spec. It is a very simple point but this helps verymuch in > > maintenance - even to have a look at the code and compare with the > > spec to see what is supported and what is not. (Just imagine how much > > effort that we have to put to compare current code with the spec) > > > > Thanks, > > Samisa... > > > > On Thu, 30 Dec 2004 11:13:46 +0000, John Hawkins <[EMAIL PROTECTED]> > wrote: > > > > > > > > > +1 for making this an Object model. > > > > > > Do we have an exception model for when the > serialisation/deserialisation > > > fails? I was specifically thinking of when the values given are out of > > > bounds. > > > To what extent is this going to resolve our issue with type constraints > - > > > My guess would be that we just want to implement the model first to > what > > > they used to be before we do any more work on ensuring that we have the > > > correct type mappings? > > > > > > John Hawkins > > > > > > Adrian Dick/UK/[EMAIL PROTECTED] wrote on 30/12/2004 08:56:08: > > > > > > > > > > > > > > > > > > > > > > > Following recent problems with Serialization/Deserialization of XSD > > > simple > > > > types, I propose a re-working of the current structure to a very > simple > > > > object oriented model mimicking the Schema heirarchy. > > > > The basic intent is to encapsulate the serialization/deserialization > > > rules > > > > within objects, one object for each simple type. These objects will > be > > > > used at every point in the code requiring the > > > serialization/deserialization > > > > of simple types, rather than the current situation where the code > occurs > > > in > > > > several places - which has been causing maintenance issues. > > > > > > > > > > > > > > > This sees the introduction of an interface which provides the > deserialize > > > > and serialize methods. The interface is to be implemented by each of > the > > > > 19 built-in primitive types (exact algorithms and values for > constraining > > > > facets to meet the XML Schema, see > > > > > http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#built-in-datatypes). > > > > The remaining 25 built-in derived types, in turn, extend from these > > > > primitive types. > > > > All the implementing classes will over-ride the getter methods for > their > > > > associated constraints with their respective values. > > > > See diagram in XSD Object Model.jpg (See attached file: XSD Object > > > > Model.JPG) (Diagram only shows a small subset of all built-in types - > see > > > > > http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#built-in-datatypes > > > for > > > > full detail) > > > > > > > > > > > > > > > > To support these are 12 interfaces, for each of the XML constraining > > > > facets, to provide validation and parsing of data being > > > > deserialized/serialized. > > > > Hopefully, each interface will have a single implementing class, but > it > > > may > > > > be necessary to have multiple implementations where the data types or > > > > algorithms are dissimilar. > > > > See diagram in Constraining Facets Object Model.jpg (See attached > file: > > > > Constraining Facets Object Model.JPG)(Diagram only shows a small > subset > > > of > > > all constraining facets - see > http://w3c.org/TR/xmlschema-2/#rf-facets > > > for > > > > full detail) > > > > > > > > > > > > > > > > The attached sequence diagrams show how the data types and > constraining > > > > facets interact for serialization and deserialization: > > > > (See attached file: Serialization Sequence.JPG)(See attached file: > > > > DeSerialization Sequence.JPG) > > > > > > > > > > > > > > > > I have identified the following points in the code for these new > objects > > > to > > > > be used: > > > > BasicTypeSerializer::serializeAsAttribute(...) > > > > BasicTypeSerializer::serializeAsElement(...) > > > > SoapDeSerializer::getAttributeAs<type>(...) - 2 occurances in > each > > > > method (RPC and Doc) > > > > SoapDeSerializer::getBasicArray(...) - " > > > > SoapDeSerializer::getElementAs<type>(...) - " > > > > SoapDeSerializer::getChardataAs(...) - this whole method will > become > > > > redundant, in fact already appears to be so. > > > > SoapSerializer::serializeAsChardata(...) - " > > > > Note: Currently, depending which sections of code you use, we only > > > support > > > > 22 or 23 of the 44 XSD built-in simple types. Is there a reason for > > > this, > > > > or should we be supporting all 44 built-in simple types? In which > case > > > we > > > > will also need to add these to > > > > org.apache.axis.wsdl.wsdl2ws.info.TypeMap.java, and ensure we have > tests > > > > for all the built-in types. > > > > > > > > It is my intention that this implementation be internal to the > runtime, > > > > probably used exclusively by SoapSerializer and SoapDeSerializer. > Though > > > > at some point in the future we may wish to extend this model to > support > > > > Complex Data types, etc., which would require externalising to allow > the > > > > WSDL2Ws generated stubs to take full advantage of the model. (But > that's > > > a > > > > while off yet!) > > > > > > > > Regards, > > > > Adrian > > > > _______________________________________ > > > > Adrian Dick ([EMAIL PROTECTED]) > > > > WebSphere MQ and ESB Development > > > > Tel: +44-(0)-1962-819212 > > > > Notes: Adrian Dick/UK/[EMAIL PROTECTED] "XSD Object Model.JPG" > > > > deleted by John Hawkins/UK/IBM] [attachment "Constraining Facets > > > > Object Model.JPG" deleted by John Hawkins/UK/IBM] [attachment > > > > "Serialization Sequence.JPG" deleted by John Hawkins/UK/IBM] > > > > [attachment "DeSerialization Sequence.JPG" deleted by John > > > Hawkins/UK/IBM] > > > > > > > > -- Damitha Kumarage hSenid Software International (PVT) Ltd [EMAIL PROTECTED] Lanka Software Foundation (http://www.opensource.lk)
