> In my opinion, this possibility can also be stated as: the possibility of
> generating an XML Shema from an instance XML document (and then compile it
> with JAXB).
I'm not sure how that might work, since it's hard to infer from an instance
document what all of the possible nodes might be. For example, if I have
<Car><Color>red</Color></Car>, it's hard to know from that what other
elements might be possible children of Car, or what the possible values of
Color are. All you can really know for sure is that Car has a child that's
called Color, and that "red" is (presumably) a valid value of Color.
> I believe that this functionality can be obtained from some XML management
> programs, but don't see the need of including it in JAXB.
I would agree with you there. It sounds neat as a concept, but would
probably be out of place.
> Instead of it, I was thinking about another functionality which could be
> interesting, to be included in JAXB or in a separate tool. It's the
> possibility of generating an XMLSchema suitable to represent the content
of
> arbitrary java classes. In fact, JAXB spec says, if I remember well, that
a
> marshaller may (but is not required to) be able to marshal any object,
> doesn't matter if it's been generated by JAXB compiler or not. This is an
> interesting feature to ease the adoption of JAXB in a previously existing
> application.
> What do you think about it?
I think that sounds interesting. I don't know if it would be the right
decision or not, but it would certainly be interesting. In particular, it
would be nice if the current XMLEncoder included in Java 1.4 (here's a link:
http://java.sun.com/j2se/1.4.1/docs/api/java/beans/XMLEncoder.html ) could
work in conjunction with JAXB at some point. Right now, the XMLEncoder (and
Decoder) work with plaintext XML, which is strangely out of place even at
this point. For example, they don't even produce DOM nodes.
I have written a public, open source utility which can convert XML produced
by the XMLEncoder into a DOM tree...which you can view at
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/singularity-sys/singularity/s
rc/com/thoughtriver/open/util/XMLUtils.java?rev=1.1&content-type=text/vnd.vi
ewcvs-markup ... (the class actually does lots of XML related stuff,
including converting Beans to and from DOM nodes). The source for this
class is included with the Singularity System source download, as well.
Now, if JAXB took over this job, so that a Bean (for example) could be
converted directly into XML code following the
currently-unknown-but-could-exist "Bean Schema", it would be quite useful.
It would make utilities like mine unnecessary.
I suppose the basic concept here would be 1) having JAXB internally include
pre-bound classes representing an implied "Bean Schema" 2) providing API
that would allow Beans to be externalized into XML using these internal
class objects.
-Brandon
Thought River South