You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by Adrian Dick <ad...@uk.ibm.com> on 2004/12/30 09:56:08 UTC
OO Model for XSD built-in simple types
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 (adrian.dick@uk.ibm.com)
WebSphere MQ and ESB Development
Tel: +44-(0)-1962-819212
Notes: Adrian Dick/UK/IBM@IBMGB
Re: OO Model for XSD built-in simple types
Posted by John Hawkins <HA...@uk.ibm.com>.
+1 for enum ordering - good point !
John Hawkins
Samisa Abeysinghe <sa...@gmail.com> 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 <HA...@uk.ibm.com>
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/IBM@IBMGB 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 (adrian.dick@uk.ibm.com)
> > > WebSphere MQ and ESB Development
> > > Tel: +44-(0)-1962-819212
> > > Notes: Adrian Dick/UK/IBM@IBMGB[attachment "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]
> >
> >
Re: OO Model for XSD built-in simple types
Posted by Samisa Abeysinghe <sa...@gmail.com>.
+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 <HA...@uk.ibm.com> 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/IBM@IBMGB 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 (adrian.dick@uk.ibm.com)
> > WebSphere MQ and ESB Development
> > Tel: +44-(0)-1962-819212
> > Notes: Adrian Dick/UK/IBM@IBMGB[attachment "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]
>
>
Re: OO Model for XSD built-in simple types
Posted by John Hawkins <HA...@uk.ibm.com>.
+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/IBM@IBMGB 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 (adrian.dick@uk.ibm.com)
> WebSphere MQ and ESB Development
> Tel: +44-(0)-1962-819212
> Notes: Adrian Dick/UK/IBM@IBMGB[attachment "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]