Nice!
I would like to propose an effort to fork the serialization and
deserialization/XML-Java Mapping subsystem to define a more generic API
based on popular frameworks already out there. While I agree that any
current API might have to be proprietary, it could be better split from
the rest of the Axis framework. I did, in fact, have to do this a while
back due some of the same limitations listed here - sequence, choice,
enums, wildcards, elements with same name and different namespaces etc.
What, in essence I am proposing is to design a metadata model for
language mappings (schema, wsdl, java MAPPINGS) and keep it distinct
from the execution framework (serializationContext does not _require_ a
messageContext ;-).
Is there any effort like this already? If not, do we have any takers?
Mukund Balasubramanian
Harald Schmitt wrote:
>Hi all,
>
>I think this would be a good FAQ point.
>
>
>
>>Hi Tim!
>>
>>It is certainly possible to store the metadata anywhere you want - the
>TypeDesc.getTypeDescForClass()
>>method is the control point there. Right now we look for a) inline static metdata,
>and b) a "Helper" class
>>which contains the metadata. This could easily be extended to include scanning for
>an XML or a
>>properties file.
>>
>>The TypeDesc class contains XML <-> Java databinding information in a
>well-structured form. The
>>BeanInfo class just gives you name/value pairs, so we'd still need to come up with
>some kind of data
>>structure to store the actual information about mapping fields/properties to XML
>elements/attributes even
>>if we got that data from BeanInfo classes. We've discussed getting the TypeDesc
>from a BeanInfo
>>structure, but haven't gone there yet.
>>
>>In terms of publishing existing beans without modifying them, this works fine in
>that a) the default
>>serialization will apply to beans with no metadata (all public fields represented as
>XML elements, and I
>>think the schema uses <all>) and b) we support external metadata in the form of a
>Helper class right
>>now, and may support other file-based formats in the future.
>>
>>TypeDesc/FieldDesc should expand to handle capturing more of what schema can do
>>(all/sequence/choice/etc), and we also hope to include a constraint system at some
>point to support
>>schema restriction types with limited value sets.
>>
>>As for "Axis-specific", any XML<->Java databinding framework (JAXB, Castor, Axis) is
>going to be
>>proprietary right now, in that the metadata gets read by some tool that is
>deserializing or serializing XML
>>in some custom way. It may be that this stuff gets standardized (that's where JAXB
>is trying to go, for
>>instance), but we're not there yet. Until a standard we like better arrives, we're
>going to try to make Axis
>>do this as efficiently and simply as we can. It's also the plan at some point to
>tease the databinding
>>framework away from the rest of Axis so that it can be used independently from, as
>well as in concert
>>with, the SOAP/Handler stuff.
>>
>>--Glen
>>
>> -----Original Message-----
>> From: Tim Blake [mailto:[EMAIL PROTECTED]]
>> Sent: Tuesday, April 23, 2002 6:52 AM
>> To: [EMAIL PROTECTED]
>> Subject: JavaBeans and metadata
>>
>> Hi,
>>
>> Could somebody please give me a summary of the design decisions taken vis-a-vis
>storing
>> metadata inline with generated complexTypes? I appreciate that this has
>already been the
>> subject of some discussion (and maybe even disagreement ;-)) and I'm genuinely
>trying to
>> understand, not just rock the boat...
>>
>> - Why do you store metadata inline, as opposed to in separate files (or maybe
>this is
>> possible as well)?
>> - Why do you use "org.apache.axis.description.TypeDesc" for describing metadata
>on
>> JavaBeans, rather than the existing BeanInfo framework? Is this intended to be
>more
>> generic than BeanInfo, since it can be used in other contexts? How does this
>"proprietary"
>> metadata layer affect the use case where people want to publish existing
>JavaBeans
>> without modifying them?
>> My real interest here is in solving the problem of mapping the XML schema
>comparators all
>> | sequence | choice into Java in the best possible non-AXIS-specific way. This
>isn't so
>> much a question of "interoperability" as "uniformity" of solution. If you've
>discussed this to
>> death previously then please point me to the relevant posts. If not, what do
>y'all think?
>>
>> Thanks,
>> Tim
>>
>>
>>
