This kind of questions should go to users_at_jaxb.dev.java.net. This alias
is for the development of the JAXB RI itself.
Andrew Hughes wrote:
> Hi All,
>
> The domain I am working with , uses schema's that are meant to be
> extended. Consequently if the extensions do not have bindings, then "to
> my knowledge" JAXB does not provide me with a usable solution?
>
> For instance if I can create valid xml from my XSD:
>
> <Business>
> <Name official="The Code Factory Pty. Ltd."/>
> </Business>
>
> But someone decides to extent the XML so it now contains a new element
> <NameAlias>:
>
> <Business>
> <Name official="The Code Factory Pty. Ltd.">
> <NameAlias alias="Code inc. Pty. Ltd./>
> <NameAlias alias="Code-Factory Pty. Ltd./>
> </Name>
> </Business>
>
>
> This is obviously not valid.... in an ideal world this should be
> rejected told to please come back with something that meets the
> specification... this is not reality however. Most people like XML
> because they can customize it... they can add their own data... and they
> can also ignore data.... Another problem is schema versioning... some
> people change their schema's.. and some don't even place version
> information to begin with.
JAXB does provide some provision for what you are describing. For
example our unmarshaller is capable of ignoring any elements/attributes
that haven't showed up in the schema. We have a binding support for
wildcard that can capture everything that didn't match the input. It's
all to this end.
> What I would really like to know (or maybe suggest) is if there is a way
> to bind and unmarshall unknown elements/attributes to a Unknown or
> Generic JAXBElement ??? If the generic/unknown JAXBElement held string
> values, and had methods/fields such as
>
> getElementName() returns the unknown/generic elements name
> getAttributes() returns List<GenericJAXBAttribute>
> getElements() returns List<JAXBElement<?>>
>
> Although it does not provide the developer with an exact schema binding
> to develop against (which I understand is a HUGE advantage)... it does
> however provide the flexibility they need from JAXB rather than just
> rejecting the XML completely. There are many reasons for this... even if
> its to raise a more helpful error message as to why their XML is broken.
Note that JAXB won't reject such XMLs. It will just silently drop those
elements that don't have a matching fields.
> Document creation and Marshalling would also allow composers of XML with
> the possibility of adding their own elements / attributes to a
> specification without breaking JAXB code bases.
It sounds like what you really want is just a thin wrapper around DOM,
so that you can access elements and attributes of your choice. Since
it's based on DOM, you can retain the complete infoset and get down to
the infoset level whenever you want.
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com