users@jaxb.java.net

Re: Retrieving substitutionGroup information from JAXBElement

From: Claus Nagel <claus.nagel_at_gmail.com>
Date: Thu, 1 Oct 2009 09:09:46 +0200

> Just to state the obvious, repeating what I think I've understood:
>
> xs:anyType results in an org.w3c.dom.Element e, which can be
> unmarshalled (provided we have the JAXB generated "bar" classes)
> with an Unmarshaller derived from a context created from a suitable
> package or class set. (You want to know is whether this Element has
> been substituted for _GenericExtensionTypeA or _...B but both of
> these are optional; the only chance is to obtain the information
> contained in some "bar" environment.)

That's exactly my problem. Thanks for your precise summary.

> My train of thoughts:
> - Unmarshalling Element e and using getValue() will tell you the
> class and its package, and the tag ("tag").
> - In this package's ObjectFactory should be a method createTag,
> returning a JAXBElement<?>.
> - Retrieving annontation @XmlElementDecl from method createTag
> should give you, in its field substitutionHeadName, the name of the
> element from foo:A.

Yes, I was afraid this is the way to go... Thank you very much,
Wolfgang. Of course, I prefer using XSOM to query the XML schema
document for the substitutionGroup of some element. However, this
means I have to load the schema into memory prior to parsing the XML
document. There might be situations when this is not feasible: e.g.,
the XML document does not provide a schema location or the schema
location points to somewhere on the network but the parsing client
does not have a network connection.

Given a user provides JAXB mappings for the resulting DOM elements,
the retrieval of the proper substitution group is not dependent on an
XSOM representation of the schema anymore. This is nice as it makes my
API more robust. However, there is a last question that comes to my
mind:

Suppose the user is putting the JAXB mappings into a .jar package (for
example, to easily share his user-defined extensions with someone
else). This means, the ObjectFactory class to be parsed is located
within this .jar file. Does this cause any trouble? I strongly suppose
it does not but as you might have guessed I do not have experience in
that.

Thanks again,
Claus