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
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
