You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@corinthia.apache.org by Ian C <ia...@apache.org> on 2015/08/29 08:56:30 UTC
ODF Explorer
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
Re: ODF Explorer
Posted by Ian C <ia...@amham.net>.
On Sun, Aug 30, 2015 at 1:16 AM, Peter Kelly <pm...@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.
I created a dummy file in the input directory so hopefully the next
cloner will not have that issue.
>
> 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.
>
> 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.
>
> 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.
>
> 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?
>
> —
> Dr Peter M. Kelly
> pmkelly@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 <pm...@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
>> pmkelly@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 <ia...@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
Re: ODF Explorer
Posted by Ian C <ia...@amham.net>.
On Sun, Aug 30, 2015 at 12:04 PM, Dave Fisher <da...@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 <ia...@amham.net> wrote:
>>
>> Hi Peter,
>>
>>
>>> On Sun, Aug 30, 2015 at 1:16 AM, Peter Kelly <pm...@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 <pm...@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
>>> pmkelly@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 <pm...@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
>>>> pmkelly@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 <ia...@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
Re: ODF Explorer
Posted by Dave Fisher <da...@comcast.net>.
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 <ia...@amham.net> wrote:
>
> Hi Peter,
>
>
>> On Sun, Aug 30, 2015 at 1:16 AM, Peter Kelly <pm...@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 <pm...@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
>> pmkelly@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 <pm...@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
>>> pmkelly@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 <ia...@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
Re: ODF Explorer
Posted by Dave Fisher <da...@comcast.net>.
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 <ia...@amham.net> wrote:
>
> Hi Peter,
>
>
>> On Sun, Aug 30, 2015 at 1:16 AM, Peter Kelly <pm...@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 <pm...@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
>> pmkelly@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 <pm...@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
>>> pmkelly@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 <ia...@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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
Re: ODF Explorer
Posted by Ian C <ia...@amham.net>.
Hi Peter,
On Sun, Aug 30, 2015 at 1:16 AM, Peter Kelly <pm...@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
> pmkelly@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 <pm...@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
>> pmkelly@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 <ia...@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
Re: ODF Explorer
Posted by Peter Kelly <pm...@apache.org>.
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.
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.
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.
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.
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?
—
Dr Peter M. Kelly
pmkelly@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 <pm...@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
> pmkelly@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 <ia...@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
>
Re: ODF Explorer
Posted by Peter Kelly <pm...@apache.org>.
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
pmkelly@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 <ia...@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
Re: ODF Explorer
Posted by jan i <ja...@apache.org>.
On 29 August 2015 at 08:56, Ian C <ia...@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 :-)
>
thanks for the heads up, I will try it out in the coming days, and
hopefully be a bit more successful as last time.
>
> I intend to post about it on other lists too. But if you deem it
> worthwhile feel free to pass it on.
>
I think it is a good idea. You should really contact POI, they are java
based and could use something like your tool.
Dave might give you a hint or two, since he is also POI.
rgds
jan i.
>
> I will also return to the round trip coding of passing ODF documents
> through Corinthia.
>
> Cheers,
>
> Ian
>