axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Jordahl <t...@macromedia.com>
Subject RE: Support for XML Schema types in Axis
Date Wed, 07 Aug 2002 17:12:54 GMT
 
Hi Wes,
 
What do you do currently for schema types like gMonthDay and time?
 
--
Tom Jordahl
Macromedia
 
 
-----Original Message-----
From: Wes Moulder [mailto:wes@themindelectric.com]
Sent: Wednesday, August 07, 2002 12:28 PM
To: axis-dev@xml.apache.org
Subject: RE: Support for XML Schema types in Axis


Hey guys,
We're having to develop our own versions of these classes for a similar reason (customer demands).
 Does it make sense to make the classes available in a common package (a la org.soapbuilders.types)
so that we have the same classes to begin with.  That way, JAX-RPC has something to work with
for these types?  (We've got something for hexBinary and duration thusfar)
 
--Wes

-----Original Message-----
From: butek@us.ibm.com [mailto:butek@us.ibm.com] 
Sent: Wednesday, August 07, 2002 10:38 AM
To: axis-dev@xml.apache.org
Subject: Re: Support for XML Schema types in Axis


+1

I understand Sam's concern, and if JAX-RPC ver 2 addresses these types, we won't be backward
compatible, but folks are asking for this support NOW. I really don't expect anyone wll want
to replace AXIS classes with their own.

It might be wise to add comments to the generated code telling them it's liable to change
(and/or to the emitter output?)

Russell Butek
butek@us.ibm.com



Please respond to axis-dev@xml.apache.org 


To: "'axis-dev@xml.apache.org'" <axis-dev@xml.apache.org>
cc: 
Subject: Support for XML Schema types in Axis



Hi all,

I am ready to check in support for a bunch of XML Schema types: time, unsignedInt, unsignedShort,
unsignedByte, and unsignedLong.  I also plan to add the types gYear and gMonthYear as soon
as I can whip them up, with possibly more types later.

How is this getting done?

The types have been implemented in the org.apache.axis.types package.  Each of the classes
enforces the restrictions of the XML type they implement.  The Schema type is mapped directly
to the corresponding Axis type.  A Serializer/Deserializer is defined for each new Schema
type.

We had previously implemented NormalizedString and Token, which were in encoding and have
moved to types.

Chris Kowalski contributed the unsigned* types as well as the NormalizedString and Token types.

What is good about this:
- It make supporting additional Schema types simple.
- There is no 'lossy' conversion of Schema types to Java types (i.e. unsignedInt -> int)
- The WSDL generated by these types survives a round-trip from WSDL->Java->WSDL.
- The semantics of these types are specific and can be enforced by their classes.
- It is simple to document and understand ("The XML Schema type "time" maps to org.apache.axis.types.Time.")

What isn't so good:
- We have introduced Axis specific classes that must be used when calling Stubs/Beans generated
by our WSDL2Java
- Dealing with the Axis UnsignedInt class isn't as simple as dealing with Java 'int'


Sam has suggested the idea that Axis should provide a configurable choice of which mappings
to use. For instance, if the user wanted the "convenience" mode, unsignedInt could be mapped
to int, time would map to Calendar, etc.  They could choose "Schema" mode, where the Axis
types are used.  Or we could somehow let the user define class mappings themselves.  I am
not opposed to this, but I do think it would make the system more complicated, albeit more
flexible.  I do not think there is anything in this submit that would prevent a system like
the above from being implemented, but I would argue that the "Schema" mode, where Axis schema
types are used, should be the default.

I plan on checking in the new type support after lunch (EDT) unless there are serious objections.

Comments?

--
Tom Jordahl
Macromedia Server Development




Mime
View raw message