Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
Most of java-xml binding implementations provide two way support.
From: Santhosh T [mailto:santhosh.tekuri@gmail.com]
Sent: 25 January 2010 09:48
To: Boris Kolpackov
Cc: xml-dev@lists.xml.org
Subject: Re: [xml-dev] A new approach for SAX-Java Binding
i.e, serializing domain object to xml
deserializing xml to domain object.
But JLibs implementation is only one way. that is "deserializing xml to domain object".
the main advantages of JLibs implementation:
1. works with hand-coded domain objects
most binding implementations mandate that domain objects has to be generated
from schema or dtd. They don't work with hand-coded domain objects
2. domain objects are not tied to binding implementation
domain objects dont need to extend/implement a particular class/interface from binding implementation.
for example,
XMLBeans mandates that all domain objects implement org.apache.xmlbeans.XmlObject
Similarly EMF mandates that all domain objects implement EObject interface
3. domain objects are light-weight. i.e not poluted with binding implementation specific information
for example: the domain objects created by XMLBeans or EMF carry lot of information which are specific
to them. This will bloat up memory.
4. easier migration.
let us say in version 2, you want to change the xml looks like, and still wants to provide backward
compatibility to end-users.
This is tedious task with other binding frameworks. With JLibs you can have different Binding implementations
for a domain object and use appropriate one at runtime based on version of xml document.
5. clear separation of binding and domain object
6. in jlibs, it is like a callback methods. callback methods can define when it has
to be called and what information from xml document you want. You have complete control how to consume that
information into domain object (because you are implementing it in java code)
7. The runtime memory used by jlibs binding is minimal and no reflection api is used
JLibs binding implementation more of resembels apache-commons-digestor implementation but without reflection
- Santhosh
On Mon, Jan 25, 2010 at 1:51 PM, Boris Kolpackov <boris@codesynthesis.com> wrote:
Hi Santhosh,
This idea might be new to Java, though something like this has been
Santhosh T <santhosh.tekuri@gmail.com> writes:
> http://code.google.com/p/jlibs/wiki/SAX2JavaBinding
>
> this shows a new approach to define sax to java binding in very intutive
> manner.
>
> your comments are welcomed;
available for C++ for several years now (see the C++/Parser[1]
mapping, for example).
I also think in your architecture you miss one of the main reasons
why people choose to use SAX over, say, DOM. Which is that they don't
want to (or cannot afford to) build an in-memory representation.
Instead, the XML data is processed as soon as it becomes available
in a pure event-driven or a partially in-memory / partially event-
driven mode.
In this light, a callback interface like this seems like a more
natural choice (using your Employee example):
public interface Employee {
public void name (String name);
public void age (int age);
public void experience (int exp);
};
In the C++/Parser mapping I mentioned above this interface as well
as the "SAX routing code" are automatically generated from XML Schema.
The user can then implement this interface to receive the data:
public class EmployeeImpl implements Employee {
public void name (String name)
{
// Handle name.
}
public void age (int age)
{
// Handle age.
}
public void experience (int exp)
{
// Handle experience.
}
};
[1] http://www.codesynthesis.com/products/xsd/c++/parser/
Boris
--
Boris Kolpackov, Code Synthesis http://codesynthesis.com/~boris/blog
Open-source XML data binding for C++ http://codesynthesis.com/products/xsd
XML data binding for embedded systems http://codesynthesis.com/products/xsde
Command line interface to C++ compiler http://codesynthesis.com/projects/cli