Are there any tools like jaxb that work with relaxng?
To the best of my knowledge, there are not (for java). The language
"binding" frameworks for RelaxNG that I have seen generally involve
annotating the RelaxNG grammar with explicit hints about how to map
schema elements to object model elements in the target language...
Where I work, we have a proprietary XML binding framework (yes, I
know, another one...) that uses RelaxNG, and I have preliminary
authorization to release it as an open-source project on Codehaus -- I
just need to get the final sign-off from the lawyers, and I'll be
sharing it out. (and we do have a track record of doing this -- the
same company has allowed us to release Atomserver - http://atomserver.codehaus.org
- so, I believe that we truly will be releasing this in weeks not
months, if there is interest...)
Anyways, the technique that we use for this framework is a little
different than most other frameworks out there - I'll outline it
quickly here:
the primary way you define your object model is by writing java
interfaces - they should use the standard JavaBeans conventions for
getters/setters. You can annotate the getters with annotations that
specify how the property should be handled in XML:
public interface Car {
@Attribute
Long getId();
void setId(Long id);
@Element
String getMake();
void setMake(String make);
@Element
String getModel();
void setModel(String model);
@CollectionElement(itemName="option", occurs = Occurs.ANY)
List<String> getOptions();
void setOptions(List<String> options);
}
you put all of the interfaces for one object model into the same java
package, and then you run the IBeans (short for interface-beans)
compiler on the package -- it generates an "implementation" package
that contains implementations for all of the bean interfaces (trivial
boilerplate code...) and a STAX marshaller/unmarshaller (using
woodstox under the covers) for each type. The compiler also generates
a RelaxNG grammar for the object model, that follows the same rules
laid out by the annotations.
At compile-time, you are only dependent on the IBeans runtime library
and your interfaces - NOT the generated package (you need to know the
NAME of the package) - so, for IDE support, it's great - you can truly
treat the generated code as an artifact of your build process:
IBeans ibeans = new IBeans("com.freedomandbeer.cars.impl");
Car car = ibeans.newInstance(Car.class);
car.setMake("Ford");
car.setModel("Mustang");
car.setOptions(Arrays.asList("chrome", "cd changer"));
StringWriter writer = new StringWriter();
ibeans.marshallDocument(car, Car.class, writer);
System.out.println(writer.toString());
Currently, the compiler outputs java source that must then be compiled
and put into the classpath at runtime -- one of the big features I'd
like to do in the next major release is to give the IBeans class a
custom classloader, and have it generate the bean implementations and
XML marshalling/unmarshalling code on the fly - so there IS no jar of
implementation classes... the only thing on the main application
classpath is the ibeans runtime and the compiled, annotated
interfaces...
FWIW - we built this framework because we really didn't find that any
of the existing binding frameworks out there quite supported all of
our needs, which were:
1) we have a lot of different schemas to maintain, and they evolve
fairly rapidly, so minimalizing the amount of code required to define
the schemas and their binding to objects was a must
2) most of these schemas define APIs to web services, and we don't
have total control over the upgrade paths of clients, so we needed
very flexible formats that allow us to roll out new features for some
clients, without breaking clients who aren't ready to move
3) these systems get a TON of traffic, so XML marshalling/
unmarshalling had to be as fast as possible
with IBeans, we only maintain ONE representation of the object model
(the annotated interfaces) and there is no separate binding
representation. By using STAX and RelaxNG, we can easily have very
open formats that are tolerant of clients changing the order of
things, etc, while still validating the things that we really care
about. Finally, by doing our unmarshalling of XML with a custom-
crafted STAX parser for each type, we know that we can both parse and
validate any document in a single pass through the parser.
anyways - that's probably enough of this for the maven list! If
there's interest in IBeans for potentially being used by maven to
manage the POMs, a post or two to that effect on this list might help
me get the legal deal expedited at work. If people have interest in
IBeans in general, email me offline and I'll let you know when I get
the package out in the wild. thanks!
- Bryon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
