Hi Ian, Your tool and the compliments it is receiving are interesting.
Including poi and Yegor. What do people think? Regards, Dave Sent from my iPhone > On Aug 29, 2015, at 8:53 PM, Ian C <i...@amham.net> wrote: > > Hi Peter, > > >> On Sun, Aug 30, 2015 at 1:16 AM, Peter Kelly <pmke...@apache.org> wrote: >> Ok I just figured out the cause - it was trying to write a file to the >> ‘input’ directory (under the ODFExplorer directory where I had run >> ‘npm start’) but that directory did not exist. After I created that, I >> was able to upload files successfully and have them processed. >> > great that you got it working. I will need to have that directory > created, I just repeated the issue. Gosh it's annoying to mess up > these little things. > >> I love the tree widget you’ve got in the UI for navigating the element >> coverage - I don’t think I’ve seen something quite like this before for >> summarising information. The closest I can think of is DiskInventoryX for >> mac which shows how much data is used by various directories on your hard >> disk. But the idea of applying it to XML structures is really cool. >> > Pleased you like the UI. I'm not a UI designer by a long shot, and > just cobble together bits that work. Like dot for the graphs. > >> I’m thinking it might be useful for us to have a web app which allows us >> to view the structure of individual documents like this, for inspection >> purposes. Once I’ve gotten Flat (my parser engine) into a state where it >> can output XML this should be doable, and would also help visualise the tree >> structure of files in non-XML formats, like Markdown. > > Absolutely, having bashed the thing into life for this ODF case I want > to try to make it more general. > >> >> The use of a web UI based on node/angular is a good idea, as it’s a nice >> way of getting a UI that works in a cross platform manner, and can also be >> deployed on a server. This also strikes me as being relevant for the >> Corinthia web app. My personal preference is for Python on the server side, >> but only because that’s what I use in my day job - node is good also and >> ultimately either choice is fine and mainly depends on whoeverâHi Peter, > > >> On Sun, Aug 30, 2015 at 1:16 AM, Peter Kelly <pmke...@apache.org> wrote: >> Ok I just figured out the cause - it was trying to write a file to the >> ‘input’ directory (under the ODFExplorer directory where I had run >> ‘npm start’) but that directory did not exist. After I created that, I >> was able to upload files successfully and have them processed. >> > great that you got it working. I will need to have that directory > created, I just repeated the issue. Gosh it's annoying to mess up > these little things. > >> I love the tree widget you’ve got in the UI for navigating the element >> coverage - I don’t think I’ve seen something quite like this before for >> summarising information. The closest I can think of is DiskInventoryX for >> mac which shows how much data is used by various directories on your hard >> disk. But the idea of applying it to XML structures is really cool. >> > Pleased you like the UI. I'm not a UI designer by a long shot, and > just cobble together bits that work. Like dot for the graphs. > >> I’m thinking it might be useful for us to have a web app which allows us >> to view the structure of individual documents like this, for inspection >> purposes. Once I’ve gotten Flat (my parser engine) into a state where it >> can output XML this should be doable, and would also help visualise the tree >> structure of files in non-XML formats, like Markdown. > > Absolutely, having bashed the thing into life for this ODF case I want > to try to make it more general. > >> >> The use of a web UI based on node/angular is a good idea, as it’s a nice >> way of getting a UI that works in a cross platform manner, and can also be >> deployed on a server. This also strikes me as being relevant for the >> Corinthia web app. My personal preference is for Python on the server side, >> but only because that’s what I use in my day job - node is good also and >> ultimately either choice is fine and mainly depends on whoever’s implement >> it. >> >> Regarding the graphs where you’ve used dot, I suggest having a look at >> some of the graph-based visualisations that d3 provides (I see you’re >> using d3 for some stuff already, but the XPath graph is in dot). I saw some >> force directed layout visualisations a colleague of mine did for a project >> we’re working on - I’ll have to check what he was using for that. > > I did look at using d3 (which is a great tool) but couldn't quite get > it to do what I wanted. And redrawing to filter the graphs and > managing it in Javascript was all to hard. I reprocess the underlying > JSON and regenerate the dot and have GraphViz regenerate the diagram. > >> >> All up, looks good so far. I’m keen to see the code for the Java side of >> things when you’re ready to make that open source. I think it could help a >> lot with our test cases, not just ODF but OOXML, depending on how easy it is >> to extend. Does the code cater for (or is it adaptable to) specifying >> alternative schemas to check against? > > Yeah, I'm getting there. And am trying to make it digestible to the > open source world and remove all the dirty laundry that it in there > :-) > > The tool uses classed generated via Apache Velocity and the Multi > Scheme Validation https://msv.java.net/ to get the schema into a from > I can generate classes from. > Which is the basis for how the ODF Toolkit generates its DOM classes. > > I always intended to do the same for OOXML, but have not been able to > get around to it. > >> >> — >> Dr Peter M. Kelly >> pmke...@apache.org >> >> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key> >> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966) >> >>> On 29 Aug 2015, at 11:58 pm, Peter Kelly <pmke...@apache.org> wrote: >>> >>> Thanks Ian >>> >>> I’ve just downloaded & built this and ran into a problem when uploading a >>> document. After selecting a .odt file and pressing “submitâ€, the node >>> server exited; here’s the output I saw: >>> >>> Field [note]: value: '' >>> note >>> Field [mode]: value: 'Singles' >>> mode case Singles >>> Field [depth]: value: 'all' >>> depthcase all >>> Filename test.odt field file1 >>> Field [submit]: value: 'Submit' >>> process -jar,odfe.jar,-f,input/test.odt >>> events.js:85 >>> throw er; // Unhandled 'error' event >>> ^ >>> Error: ENOENT, open 'input/test.odt' >>> at Error (native) >>> >>> — >>> Dr Peter M. Kelly >>> pmke...@apache.org >>> >>> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key> >>> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966) >>> >>>> On 29 Aug 2015, at 1:56 pm, Ian C <i...@apache.org> wrote: >>>> >>>> Hi All, >>>> >>>> I have been beavering away on the ODF tool I developed and making it >>>> open source via GitHub. >>>> >>>> I still have a bit of work to do to make the command line tool open >>>> source but the application is available. >>>> >>>> What the tool is and can do is not immediately obvious so I tried to >>>> document that see http://hammyau.github.io/ODFExplorer/ >>>> >>>> If you have the time check it out. It may provide a welcome distraction :-) >>>> >>>> I intend to post about it on other lists too. But if you deem it >>>> worthwhile feel free to pass it on. >>>> >>>> I will also return to the round trip coding of passing ODF documents >>>> through Corinthia. >>>> >>>> Cheers, >>>> >>>> Ian >>> >> > > > > -- > Cheers, > > Ian C
