Hi @axfelix, @jmacgreg and kaschioudi (could not find your account here),
I just wanted to thank you for the work you have done with OJS3-Markup plugin GitHub - kaschioudi/ojs3-markup: markup plugin for OJS3 and the Open Typesetting Stack. Already now they are producing nice results. Also, the Texture editor is something we are really looking forward to.
Secondly, and this is just for the other users testing the plugin, if you download the plugin from Github you have to rename the plugin folder to markup, so removing only the -master part is not enough in this case.
Those two commas were only added in the most recent commit, and I’ve been testing from the last one – I’ll let my colleague know.
The plugin should in fact use the article metadata stored in the OJS database when creating the front page of the XML; I’ll double-check whether that was broken in the most recent commit as well. Otherwise, glad you’ve been able to get up and running on your own, and we appreciate the interest in the work and the kind words.
If it helps (if you have some logs or something) it was job id 647 here http://pkp-xml-demo.lib.sfu.ca. If you can, you are free to access that job in your demo server and check the files there.
The submission had author data, title and abstract but none of these made it to the front part of the xml file. Instead, the author names were taken from the article text (not the correct names but a title of figure 1) and the abstract was actually the whole text of the.
We are planning a XML-in workflow with some of our journals and I was already planning to write a plugin which would create the front part of JATS XML file, but then started to look at you code more closely.
We’re seriously considering implementing CaSSius – our PDF generation workflow is pretty poor, and is in there at the moment because we were generating a static HTML+js page from the XML for a while (rather than just using Lens for the browser view as we do now), and it was easiest to just derive the PDF from that HTML.
The “abstract being replicated into the body text” is a known issue, and has been extremely difficult for us to fix; we use a few different parsers and they tend to disagree over where the front matter ends and the body text begins, so when we merge the result this happens often. The other problems you’re describing shouldn’t happen, though, so I’ll let you know what I find.
I described the abstract problem poorly. I mean that the abstract I have in OJS article metadata is not used in front->article-meta->abstract. Instead, the whole article text is there. I do not have a separate abstract in the docx file I am converting.
A similar situation is with the article title. The front->article-meta->article-title in the converted xml is the first title in the docx, not the article title available from the OJS article metadata. I guess this could be intended behaviour and I only noticed it because I had a different title there.
I do not know whether you were able to fix something already, but the latest conversion I did (with the same docx) now has the OJS article metadata in the front part as expected! I did switch my server, but I do not think that it would affect this somehow. Anyway, thank you!
I noticed, which is of course visible also in the markup code, that there are several fields in the OJS metadata which are not used when producing the JATS XML. These include:
ISSN
Detailed author name (surname + given-names)
Affiliation
Article pub-id
journal-id
possibly other metadata like keywords
Also, there is some information that would be available when the article is published, but this is of course something that would have to be added in OJS. I am talking about publication dates, volume, issue etc.
Hello, after copying the 0js3-markup into the generic plugins dir, plugin list running into endless loop.
the jatsfrontpuller is an miracle too. How did this plugin work?
Thanks in advance
Stephan
I do not maintain OJS3-markup, but which version of the plugin did you try? The repository in the PKP Github account is fairly old and in general the plugin is under development, if I have understood correctly.
For the jatsfrontpuller (great name huh ) I actually just did a couple of pull requests to both OJS3-markup and the open typesetting stack which take into account the metadata I listed above. So basically, when those are merged (they seemed to be a bit buggy at this point) the jatsfrontpuller plugin will not be needed anymore for the xml workflow.
Dear ajnyga, i tryed it with GitHub - ajnyga/OJS3XMLWorkflow.
as you described: i wouldnt work
Convert production ready DOCX to XML using Markup plugin (GitHub - kaschioudi/ojs3-markup: markup plugin for OJS3)
not installable as generic plugin, no function as gateway plugin only an 500 server error in a hook call.
Open the ready JATS XML file in a editor (XML editor or text editor like Notepad++)
no problem
Create the front section of the JATS XML file with jatsFrontPuller plugin (GitHub - ajnyga/JatsFrontPuller)
how could i call this ? it seems not integrated in ojs submission or metadata menues
Clean and check the body and back sections manually
Upload the ready XML galley to OJS
If needed, create the PDF file with cassiusPrinter plugin (forthcoming)
That is really a work-in-progress workflow I just wanted to document for myself.
Regarding the ojs3-markup, that is maintained by PKP, but it should work. I am however not sure if some changes made during the last couple of months are causing an error. I have not used it myself since May.
For the jatsfronpuller plugin, I can check if the version in github has a problem of some sort. In short, it adds an textarea to the submission metadata view and writes the document front part there. But as I said above, this plugin is hopefully not needed anymore after the few additions to ojs3-markup.
My viewpoint to the XML first workflows is that at the moment we do not have the necessary tools available, but we are close and getting there. The open typesetting stack is really promising and just a couple of days ago I saw a new test version of the Texture XML editor which was very very good!
) I actually just did a couple of pull requests to both OJS3-markup and the open typesetting stack which take into account the metadata I listed above. So basically, when those are merged (they seemed to be a bit buggy at this point) the jatsfrontpuller plugin will not be needed anymore for the xml workflow.
