The fundamental flaw (as I see it - sorry) of your approach is that you
search for
dynamic *element *substitution. While the XML schema does provide this
feature,
I don't see that it is a particularly good way of thinking about Java class
hierarchies.
If some field is restricted to refrences from a class hierarchy rooted at
ExprType,
you declare that field with this (abstract or not) ExprType, or
java.lang.Object,
if all else fails.
If you just declare your fields with the appropriate base type, the
generated schema
will be reasonable enough, showing type extension for subtypes, and that's
as good
an indication as any for what's going on. - If you use Object as a type,
you'll see
xs:any in the schema, and that's the most substitutable schema type there
is.
I doubt whether and XML schema is the anywhere near "readable", as
reasonable documentation should be. All the more so, as a schemagen
generated
schema won'teven contain comments. Using doclets might be a much better
approach,
I'm not sure what you mean by "dynamic inheritance" and "type substitution".
It certainly is possible to load additional Java classes at runtime and
instantiate objects from them and store their references in fields with
a suitable type. You don't need schemas for that!
Referring to @XmlElementDecl and the ObjectParser snippet, I should
say that the XML Schema language and Java provide different (albeit
overlapping) ways of defining data types and structures. It's to be
expected that features that have no direct equivalent in one or the other
cannot be produced by a compiler or schema generator.
-W
On Wed, Mar 25, 2009 at 3:28 PM, Tuomas Kiviaho <tuomas.kiviaho_at_iki.fi>wrote:
>
>
> Wolfgang Laun-2 wrote:
> >
> > Well, this theoretic discussion won't get us anywhere as I don't clearly
> > see what you are trying to achieve. Could you provide an example?
> >
> I am trying to achieve dynamic element substitution. The example below is
> derived from
> <
> http://www.nabble.com/schemagen-and-using-%40XmlElementRef-on-a-non-collection-property-td11532413.html
> >
>
> public class FilterType extends ProcessorType {
>
> @XmlElementRef
> private ExpressionType expression;
>
> produced (although I doubt it does anymore since member isn't of parametric
> type)
> ...
> <xs:choice ...>
> <xs:element ref="tns:groovy"/>
> <xs:element ref="tns:ognl"/>
> <xs:element ref="tns:ruby"/>
> <xs:element ref="tns:xpath"/>
> </xs:choice>
>
> but what I'm after is dynamic element substitution like below (and I guess
> that the 2.1.10 schemagen also (partially) produces because member isn't of
> parametric type)
> ..
> <xs:element ref="tns:expression" ... />
> ...
> <xs:element name="expressionType" abstract="true" />
> <xs:element name="groovy" substitutionGroup="tns:expressionType" />
> <xs:element name="ognl substitutionGroup="tns:expressionType" />
> <xs:element name="ruby" substitutionGroup="tns:expressionType" />
> <xs:element name="xpath" substitutionGroup="tns:expressionType" />
>
>
> Wolfgang Laun-2 wrote:
> >
> > Since you are obviously annotating Java classes: what will you be
> > needing the generated schema for?
> >
> I use it only for document validation purposes. JAXB
> unmarshalling/marshalling isn't what I'm after. And all of the information
> should come from annotations.
>
>
> Wolfgang Laun-2 wrote:
> >
> > I don't see the problem with @XmlElements/_at_XmlElement: The
> > element's namespace is/can be inherited.
> >
> In above example the idea is to have dynamic inheritance just like one has
> with type substitution. Although the generation in the original was dynamic
> the result is static. I can't brind along substitution candidates just by
> introducing a new schema to the document
>
>
> Wolfgang Laun-2 wrote:
> >
> > In your first email you refer to @XmlElementDecl being connected
> > to substitution groups - I think you meant @XmlElementRef?
> >
> @XmlElementRef indeed. @XmlElementDecl is the one in charge of producing
> the
> global elements and I expected to get the substitutionGroup attributed
> global elements to the above example as declared in the following example
>
> @XmlRegistry
> public class ObjectParser {
>
> @XmlElementDecl(name = "groovy", substitutionHeadName =
> "expressionType")
> public JAXBElement<GroovyExpressionType>
> createGroovyExpressionType(GroovyExpressionType expressionType) {
> ...
> @XmlElementDecl(name = "ongl", substitutionHeadName =
> "expressionType")
> public JAXBElement<ONGLExpressionType>
> createONGLExpressionType(ONGLExpressionType expressionType) {
> ...
> @XmlElementDecl(name = "ruby", substitutionHeadName =
> "expressionType")
> public JAXBElement<RubyExpressionType>
> createRubyExpressionType(RubyExpressionType expressionType) {
> ...
> @XmlElementDecl(name = "xpath", substitutionHeadName =
> "expressionType")
> public JAXBElement<XPathExpressionType>
> createXPathExpressionType(XPathExpressionType expressionType) {
> ...
> --
> View this message in context:
> http://www.nabble.com/Generating-substitution-groups-in-schema-tp22698884p22702865.html
> Sent from the java.net - jaxb users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
> For additional commands, e-mail: users-help_at_jaxb.dev.java.net
>
>