On Sun, Aug 30, 2015 at 12:04 PM, Dave Fisher <dave2w...@comcast.net> wrote: > Hi Ian, > > Your tool and the compliments it is receiving are interesting. > > Including poi and Yegor. What do people think?
Thanks the more the merrier. But at the moment the tool only processes ODF documents. Extending to OOXML is a future goal. > > 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 -- Cheers, Ian C
