jQuery XML to JSON Plugin

[Colin Clark]

Hey David,

Thanks for the update. Some thoughts below...

On 10-Jun-09, at 1:09 PM, David Trelles wrote:

> Hi everyone,
>
> This is David from Barcelona. After reading and researching about  
> xml, json, jquery I found a plugin "jQuery XML to JSON Plugin"  http://www.fyneworks.com/jquery/xml-to-json/ 
>  ( MIT License and the GPL License). I think this plugin that  
> converts from xml to json is a good solution.

Can you tell us a bit more about the advantages of this particular  
plugin? For those who are curious, here's the source code for it:

http://jquery-xml2json-plugin.googlecode.com/svn/trunk/jquery.xml2json.js

As we all dig deeper into the McCord data in particular--and the  
problem of converting XML to JSON in general--some interesting  
questions arise. Here's an example from Hugues' data:

<imagefile id="664223" format="mini" label="Square" height="74"  
width="74" filesize="5" sizeunit="kB">http://www.mccord-museum.qc.ca/ThumbView/M996.10.62.jpg 
</imagefile>

This particular chunk of markup initially appears pretty  
straightforward to convert to JSON. You'd probably create an object  
called imagefile, that might look something like this:

imagefile: {
    id: 664223,
    format: "mini",
    label: "Square",
    height: "74",
    width: "74",
    filesize: "5",
    sizeunit: "kB"
}

But then there's an interesting problem. What do you do with the URL  
nested inside the <imagefile> tag? Should it be an attribute of the  
imagefile object? If so, what should it be called? I'm not sure what  
your XML to JSON plugin does in the particular scenario. It would be  
interesting to see the output of it.

Either way, this particular issue highlights the fact that our import  
process can't be entirely generic. Undoubtedly we'd like it to be as  
general as possible, so we clearly need some way to express content- 
specific processing rules. I can't see any way that we'd do this with  
the jQuery plugin, except to crack open their code and modify it  
directly.

Totally off the top of my head, I can imagine these rules could be  
expressed entirely declaratively, mapping a bit of XPath from the  
source document into an EL path in the resulting JSON structure.

Interesting stuff! Just for comparison, here's what Yura's  
implementation looks like in Python. At the moment, he hardcodes a  
rule that takes the URL and adds it to a "textvalue" propery on the  
imagefile object.

http://issues.fluidproject.org/secure/attachment/10632/patch.txt


> I've tried this plugin with Mccord xml data and it worked perfectly.  
> We have to see then with Jura and Michelle how we can import  
> directly from xml to Couch with this plugin or something similar.
Can you post your code as a patch file to your JIRA issue so we can  
take a look at your implementation? Perhaps it would also be helpful  
to attach some sample output, too.

http://issues.fluidproject.org/browse/FLUID-2882

As for the next step of importing your JSON data into CouchDB, it's  
really just a matter of making a POST request to the database to  
persist your data. Can you hang out in the IRC channel and stay in  
touch with Yura and Antranig about these issues? This will be much  
easier if we all stay in touch in the channel, keeping each other  
updated on our progress.

> Tell me what you think about it. I think we should do a demo for All- 
> hands meeting with a xml from mccord or other museums and convert it  
> to json and then we import it to CouchDB.

That is the plan, yes.

Our goal is to have some real, comparative examples of the data  
conversion and import process. We're implementing three different  
versions that run in JavaScript on the client, JavaScript on the  
server, and in Python. With some added profiling information, this  
should provide us with a good comparison of the performance of each  
implementation and the overall experience of building them. That'll  
help me with the server-side technology decision, too.

We'd like to have these prototypes in place before the all-hands  
meeting so that the dev team can have the opportunity to talk through  
the implementations, compare notes, and define our next steps at the  
meeting.

Hope this helps. I'd love to hear everyone's thoughts on all of this!

Keep it coming,

Colin

---
Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
http://fluidproject.org