Mark, whilst Ralf has already mentioned most of the relevant things, let me just address one particular topic in-line.
Werner Ralf Joachim wrote: > Hi Mark, > > as JAXB not only introspects the classes with java reflection API but > also looks at annotations we initialy planed to require Java 5. > > If there is some interest for a Java 1.4 I can think of 2 possible > approaches how this could be achived: > > 1. Make the layer that introspects classes plugable. So we could provide > a 1.4 compliant introspection layer that only use reflections and > another one that also takes annotations into account. > > 2. Use some 1.4 compatible libraries that allow to access annotations. > > The problem is that both solutions will require some additional work and > we like to focus on the function first. But if there are volunteers that > like to help us at implementation of xml schema generator we may change > our mind and go for a 1.4 compatible solution from the begining. > > I agree with you that a mapping to schema generator wouldn't be too > difficult. I am not sure whether Castor should support all possible option sfor going back and forth between Java classes, mapping files, XML schemas et alias. Looking at the JAXB schema specification, it is clear that the following two combinations have to be supported: XML schema --> (annotated) Java classes (annotated) Java classes --> XML schema And that's what we'll be providing at the end of this exercise. Right now, we support the former only (excluding JAXB annotations). But we do support creation of e.g. mapping files from Java classes and XML schemas from an XML instance document. Let's see where we are in a few weeks time once the Google SoC program has finished. Having said that if you wanted the opposit we could offer you > our code generator which not only generates java source code from an xsd > but also supports to create a mapping file that would fit for the > classes generated. > > Regards > Ralf > > > Mark Hansen schrieb: >> Thanks Werner. >> >> So, this will be a Java 1.5+ dependent feature? I was actually hoping >> for a Java 1.4 solution. >> >> I have not looked at the Castor source, but it seems - at least >> theoretically, that it would not be too difficult to recursively build >> an XML schema from a mapping file so that all XML generated by the >> mapping file would validate against the schema. I think the hard part >> would be going the other way. I'll bet that the schema wouldn't be >> "tight enough", so that there would be instances that validate but >> can't be unmarshalled into the original Java class. >> >> Do you have any thoughts on that? >> >> -- Mark >> >> Werner Guttmann wrote: >> >>> Mark, >>> >>> not yet, to be honest. As part of the upcoming JAXB 2.x compatibility we >>> are adding a schema generator that allows you to generate an XML schema >>> from a set of Java classes. >>> >>> Having said that, this will not be available (in a controlled way) for >>> several weeks. If you happen to have some time available, any >>> contributions from your side would be appreciated. >>> >>> Regards >>> Werner >>> >>> Mark Hansen wrote: >>> >>> >>>> MappingTool generates a default mapping file for a Java class. Is >>>> there >>>> any extension of MappingTool that can also give an XML Schema that >>>> accurately describes the document instances produced by marshalling via >>>> the default mapping file. I.e., a default schema that is bound to the >>>> Java class? >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe from this list please visit: >>>> >>>> http://xircles.codehaus.org/manage_email >>>> >>>> >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe from this list please visit: >>> >>> http://xircles.codehaus.org/manage_email >>> >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this list please visit: >> >> http://xircles.codehaus.org/manage_email > > --------------------------------------------------------------------- > To unsubscribe from this list please visit: > > http://xircles.codehaus.org/manage_email > > --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
