views:

155

answers:

3

In Java, we work a lot with JAXB2. Object<->XML mappings are defined as annotations in Java classes:

@XmlRootElement(name="usertask", namespace="urn:test")
public class UserTask
{
    @XmlElement(namespace="urn:test")
    public String getAssignee() { ... }

    public void setAssignee(String assignee) { ... }
}

JAXB runtime can read these annotations and create unmarshaller to parse XML into an object instance or marshall an object into XML.

JAXB ships a schema compiler (XJC) which can generate annotated classes out of XML Schemas, which is another great feature.


Lately we've been working a lot with client-side JavaScript. An we also need XML processing there. For example, we need to parse WPS documents like this one. These documents also comply to different XML schemas (here's the WPS 1.0.0 schema for the sample XML). It would be great to work with JavaScript objects instead of XML, this saves really huge amount of effort. In some cases we can use JSON-based solutions like DWR, but in many cases we do have to process XML on the client-side.

My question is:

Is there some analog of JAXB for JavaScript?

Some tool which would compile an XML Schema into some XML<->object mapping and provide a runtime to convert between XML and JavaScript objects?

I could easily imagine mappings generated in a form like:

UserTask = new JSXML.XmlRootElement({
  name: "usertask",
  namespace: "urn:test",
  properties: [
    {
      assignee: new JSXML.XmlElement({
        name: "assignee",
        namespace: "urn:test",
        type: new JSXML.XSD.String()
      })
    }
  ]
});

And this should be pretty enough to build unmarshaller or marshaller.

+2  A: 

What you can do is add a generic stylesheet definition: XSLT to your XML to convert them in JSON. eg: http://code.google.com/p/xml2json-xslt/

Handling XML with Javascript is a pain compared to JSON, especially cross browser.
The stylesheet will add a small overhead to your request. Either on the server or client side, you can choose, but you have to compare this to the code complexity and speed to parse and read the XML with Javascript on different browsers.

Mic
The XSLT solution is not suitable for a number of reasons.First, we need a client-side processing. Bringing an XSLT processor to convert from XML into JSON is way too heavy, unacceptably heavy. I think XSLT is not the best choice of technology here anyway: what can be done with a 7K XSLT can be done with 3K JavaScript - an you won't need an XSLT processor on the client side.
lexicore
Second, an XSLT like the one you posted the link to is not schema-specific. For instance, if you have an <item>foo</item> element, you'll actually don't know if this must be a single item: 'foo' or an array item: ['foo']. Having 2010 you don't know if it's a year or a number and so on. XML<->object mapping must be schema-derived here to provide appropriate structure and type information which an XML instance per se does not provide.
lexicore
Adding a header like `<?xml-stylesheet type="text/xml" href="xml2json.xsl"?>` in your XML's is understood by all browsers without adding anything, or you can make it server side(nginx is really good at that). Moving to JSON imply some tradeoffs, especially regarding schemas, types etc... But for me it is worth the loss.
Mic
+3  A: 

To date, I have found nothing similar to what I need. Therefore I've deсided to implement it myself. Here's the project page:

http://confluence.highsource.org/display/MISC/Jsonix

The project is hosted on SourceForge:

https://sourceforge.net/projects/jsonix

lexicore
+1  A: 

I haven't tried this, so I'm not sure if it will work, but have you considered using GWT so that you can still use JAXB and write the whole app as a java app? I'm not sure if GWT supports JAXB (probably not), but there might be an alternative for xml parsing that it will support. If this works, you could automate the creation of your javascript models via gwt, and then include these into your app. Yes, it's a lot more cruft than you want, but beats having to write it from scratch.

Ben Taitelbaum