Just realized that there's no built-in framework for NLM documents. Any barrier to that or just no demand? Cheers, E. -- Eliot Kimber Senior Solutions Architect "Bringing Strategy, Content, and Technology Together" Main: 512.554.9368 www.reallysi.com www.rsuitecms.com
Hi Eliot, There were no requests as far as I remember. I am not aware of any technical difficulties. What I would like to have is an area on our website where people can post and share frameworks for different vocabularies. These should be also discoverable from oXygen so you can browse the available frameworks and decide to get some of them locally. Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com On 9/28/10 10:09 PM, Eliot Kimber wrote:
Just realized that there's no built-in framework for NLM documents.
Any barrier to that or just no demand?
Cheers,
E.
A place to share would be nice. I hacked a very quick framework out of a CSS lying about so at least I can get automatic in-editor formatting. I hadn't really appreciated how easy it is to set up a framework until I tried to do it. I'm starting a client project that will involve managing NLM documents and will support light editing with Oxygen (essentially small editorial corrections to files produced by data conversion houses). I don't expect to need to do more than set up some basic buttons and CSS styles. As far as I can tell it's pretty rare for people to author directly in NLM--most journal workflows are non-XML with XML produced at the end from whatever the original source was. Cheers, Eliot On 9/29/10 4:05 AM, "George Cristian Bina" <george@oxygenxml.com> wrote:
Hi Eliot,
There were no requests as far as I remember. I am not aware of any technical difficulties.
What I would like to have is an area on our website where people can post and share frameworks for different vocabularies. These should be also discoverable from oXygen so you can browse the available frameworks and decide to get some of them locally.
Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com
On 9/28/10 10:09 PM, Eliot Kimber wrote:
Just realized that there's no built-in framework for NLM documents.
Any barrier to that or just no demand?
Cheers,
E.
-- Eliot Kimber Senior Solutions Architect "Bringing Strategy, Content, and Technology Together" Main: 512.554.9368 www.reallysi.com www.rsuitecms.com
Hi, At 06:42 AM 9/29/2010, Eliot wrote:
A place to share would be nice. I hacked a very quick framework out of a CSS lying about so at least I can get automatic in-editor formatting. I hadn't really appreciated how easy it is to set up a framework until I tried to do it.
I also have pieces lying around ... :-)
I'm starting a client project that will involve managing NLM documents and will support light editing with Oxygen (essentially small editorial corrections to files produced by data conversion houses). I don't expect to need to do more than set up some basic buttons and CSS styles.
Since Eliot has Java-fu, he might want to do the buttons stuff, but I also have CSS he could use or adapt, which is reasonably complete for the Publishing or Authoring (although not Archiving) DTDs.
As far as I can tell it's pretty rare for people to author directly in NLM--most journal workflows are non-XML with XML produced at the end from whatever the original source was.
That's largely true, especially since the tag set was originally designed to be a clean target for transformation from existing source data (much of it already in SGML or XML), not a production tag set as such. But it's perfectly useful for that purpose, especially if you bring the same sort of tagging discipline as you would to, say, Docbook or TEI. And there's more of that happening all the time. So a journal publisher may start with NLM as an interchange format for materials submitting to Pubmed Central. But then they discover that investments made there can pay off further back in the document workflow. There are already some early movers using NLM variants behind production systems (some of them not small). This means there is opportunity for editing applications in this space, if not for much authoring as such (conversion vendors and applications will still have a role as long as word processors don't go away), then at least for copy editing and document QA. While in comparison to, say, DITA (which serves the needs of a different sort of document production), the uptake of the NLM JATS ("Journal Article Tag Set") will be slow, there's also no reason to think it won't also be steady and, eventually, strong. Cheers, Wendell ====================================================================== Wendell Piez mailto:wapiez@mulberrytech.com Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9635 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ======================================================================
On 9/29/10 4:46 PM, "Wendell Piez" <wapiez@mulberrytech.com> wrote:
So a journal publisher may start with NLM as an interchange format for materials submitting to Pubmed Central. But then they discover that investments made there can pay off further back in the document workflow. There are already some early movers using NLM variants behind production systems (some of them not small). This means there is opportunity for editing applications in this space, if not for much authoring as such (conversion vendors and applications will still have a role as long as word processors don't go away), then at least for copy editing and document QA.
While in comparison to, say, DITA (which serves the needs of a different sort of document production), the uptake of the NLM JATS ("Journal Article Tag Set") will be slow, there's also no reason to think it won't also be steady and, eventually, strong.
Not if I have anything to do with it :-) That is, I would much rather define a STM vocabulary set for DITA that includes OOTB to-NLM transforms than encourage any of my clients to author in NLM directly. Just saying. Cheers, E. -- Eliot Kimber Senior Solutions Architect "Bringing Strategy, Content, and Technology Together" Main: 512.554.9368 www.reallysi.com www.rsuitecms.com
Dear Eliot, At 06:26 PM 9/29/2010, Eliot Kimber wrote:
On 9/29/10 4:46 PM, "Wendell Piez" <wapiez@mulberrytech.com> wrote:
So a journal publisher may start with NLM as an interchange format for materials submitting to Pubmed Central. But then they discover that investments made there can pay off further back in the document workflow. There are already some early movers using NLM variants behind production systems (some of them not small). This means there is opportunity for editing applications in this space, if not for much authoring as such (conversion vendors and applications will still have a role as long as word processors don't go away), then at least for copy editing and document QA.
While in comparison to, say, DITA (which serves the needs of a different sort of document production), the uptake of the NLM JATS ("Journal Article Tag Set") will be slow, there's also no reason to think it won't also be steady and, eventually, strong.
Not if I have anything to do with it :-)
That is, I would much rather define a STM vocabulary set for DITA that includes OOTB to-NLM transforms than encourage any of my clients to author in NLM directly.
Well, of course you would. And then your clients will have a business decision to make. This list isn't the place to argue comparisons between different vocabularies or how they fit into hypothetical production systems, document workflows or business models. So I'll content myself with saying that (a) they are different, and comparisons between their different strengths and weaknesses is possible and necessary; and (b) XML has been successful largely because it isn't locked down to a single tag set. (At least IMO, this has been a big factor.) If it were more important to use a single vocabulary than to address our local requirements, we'd all be using HTML. Or something. Cheers, Wendell ====================================================================== Wendell Piez mailto:wapiez@mulberrytech.com Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9635 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ======================================================================
Yes, this is not the venue to argue implementation approaches. Just pointing out that I would not bank on much future direct authoring of NLM. Cheers, E. On 9/29/10 5:58 PM, "Wendell Piez" <wapiez@mulberrytech.com> wrote:
Dear Eliot,
At 06:26 PM 9/29/2010, Eliot Kimber wrote:
On 9/29/10 4:46 PM, "Wendell Piez" <wapiez@mulberrytech.com> wrote:
So a journal publisher may start with NLM as an interchange format for materials submitting to Pubmed Central. But then they discover that investments made there can pay off further back in the document workflow. There are already some early movers using NLM variants behind production systems (some of them not small). This means there is opportunity for editing applications in this space, if not for much authoring as such (conversion vendors and applications will still have a role as long as word processors don't go away), then at least for copy editing and document QA.
While in comparison to, say, DITA (which serves the needs of a different sort of document production), the uptake of the NLM JATS ("Journal Article Tag Set") will be slow, there's also no reason to think it won't also be steady and, eventually, strong.
Not if I have anything to do with it :-)
That is, I would much rather define a STM vocabulary set for DITA that includes OOTB to-NLM transforms than encourage any of my clients to author in NLM directly.
Well, of course you would. And then your clients will have a business decision to make.
This list isn't the place to argue comparisons between different vocabularies or how they fit into hypothetical production systems, document workflows or business models. So I'll content myself with saying that (a) they are different, and comparisons between their different strengths and weaknesses is possible and necessary; and (b) XML has been successful largely because it isn't locked down to a single tag set. (At least IMO, this has been a big factor.)
If it were more important to use a single vocabulary than to address our local requirements, we'd all be using HTML. Or something.
Cheers, Wendell
====================================================================== Wendell Piez mailto:wapiez@mulberrytech.com Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9635 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ======================================================================
_______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user
-- Eliot Kimber Senior Solutions Architect "Bringing Strategy, Content, and Technology Together" Main: 512.554.9368 www.reallysi.com www.rsuitecms.com
Pulling this back to the orignal thread, I'd also like to see built-in frameworks for the library community: * Dublin Core * DDI (well, it's not really for librarians so much, but I'd like it) * EAC-CPF * EAD (already there :-) * MARCXML * METS * MODS * TEI (already there :-)
Dear Eliot, (Sorry, I was out yesterday.) At 07:08 PM 9/29/2010, you wrote:
Yes, this is not the venue to argue implementation approaches. Just pointing out that I would not bank on much future direct authoring of NLM.
Even given that that's arguable (over beer, preferably), oXygen's Authoring features are really nice for all kinds of things besides authoring directly -- I'm thinking of editorial and sub-editorial tasks, validation against house rules and house style, stuff like that. So, sure, journal article authors may persist in using word processors for a long time to come (I even have a thesis for a conference paper waiting in the wings on why that is) -- and yet support for NLM authoring could still be a strategic asset for oXygen. So to me, the question isn't so much how useful an NLM/JATS framework for oXygen would be, but how to motivate the work. I (and Mulberry) have other stuff in our kit besides CSS that could be useful for this, if anyone's interested. Just no time to do anything with it. :-) Cheers, Wendell ====================================================================== Wendell Piez mailto:wapiez@mulberrytech.com Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9635 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ======================================================================
Point taken. I will happily accept any useful NLM support bits and try to integrate them into an NLM framework. Cheers, E. On 10/1/10 9:33 AM, "Wendell Piez" <wapiez@mulberrytech.com> wrote:
Dear Eliot,
(Sorry, I was out yesterday.)
At 07:08 PM 9/29/2010, you wrote:
Yes, this is not the venue to argue implementation approaches. Just pointing out that I would not bank on much future direct authoring of NLM.
Even given that that's arguable (over beer, preferably), oXygen's Authoring features are really nice for all kinds of things besides authoring directly -- I'm thinking of editorial and sub-editorial tasks, validation against house rules and house style, stuff like that. So, sure, journal article authors may persist in using word processors for a long time to come (I even have a thesis for a conference paper waiting in the wings on why that is) -- and yet support for NLM authoring could still be a strategic asset for oXygen.
So to me, the question isn't so much how useful an NLM/JATS framework for oXygen would be, but how to motivate the work.
I (and Mulberry) have other stuff in our kit besides CSS that could be useful for this, if anyone's interested. Just no time to do anything with it. :-)
Cheers, Wendell
====================================================================== Wendell Piez mailto:wapiez@mulberrytech.com Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9635 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ======================================================================
_______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user
-- Eliot Kimber Senior Solutions Architect "Bringing Strategy, Content, and Technology Together" Main: 512.554.9368 www.reallysi.com www.rsuitecms.com
I am finally starting on my journals-related project and so now have a mandate (and time) to put together a proper NLM framework for Oxygen. Wendell--I'll take whatever you're willing to share. Cheers, E. On 10/1/10 10:17 AM, "Eliot Kimber" <ekimber@reallysi.com> wrote:
Point taken.
I will happily accept any useful NLM support bits and try to integrate them into an NLM framework.
Cheers,
E.
On 10/1/10 9:33 AM, "Wendell Piez" <wapiez@mulberrytech.com> wrote:
Dear Eliot,
(Sorry, I was out yesterday.)
At 07:08 PM 9/29/2010, you wrote:
Yes, this is not the venue to argue implementation approaches. Just pointing out that I would not bank on much future direct authoring of NLM.
Even given that that's arguable (over beer, preferably), oXygen's Authoring features are really nice for all kinds of things besides authoring directly -- I'm thinking of editorial and sub-editorial tasks, validation against house rules and house style, stuff like that. So, sure, journal article authors may persist in using word processors for a long time to come (I even have a thesis for a conference paper waiting in the wings on why that is) -- and yet support for NLM authoring could still be a strategic asset for oXygen.
So to me, the question isn't so much how useful an NLM/JATS framework for oXygen would be, but how to motivate the work.
I (and Mulberry) have other stuff in our kit besides CSS that could be useful for this, if anyone's interested. Just no time to do anything with it. :-)
Cheers, Wendell
====================================================================== Wendell Piez mailto:wapiez@mulberrytech.com Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9635 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ======================================================================
_______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user
-- Eliot Kimber Senior Solutions Architect "Bringing Strategy, Content, and Technology Together" Main: 512.554.9368 www.reallysi.com www.rsuitecms.com
_______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user
-- Eliot Kimber Senior Solutions Architect "Bringing Strategy, Content, and Technology Together" Main: 512.554.9368 www.reallysi.com www.rsuitecms.com
I am having an issue getting conref to work in a virtual directory structure. Using conref="../../mydirectory/filename.xml#id" doesn't work but when using the fully qualified path: conref="file:///K:/maindirectory/mydirectory/filename.xml#id" works perfectly. Is there a trick to getting virtual directory structures working? It looks like Oxygen is looking on the C: drive gives the following error message: Error while parsing external reference: 'file:/mydirectory/filename.xml#id. Cause: C:\mydirectory\filename.xml (The system cannot find the path specified) I feel like this is probably a simple configuration in Oxygen. TIA! Betty /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Betty Harvey | Phone: 410-787-9200 FAX: 9830 Electronic Commerce Connection, Inc. | harvey@eccnet.com | Washington,DC XML Users Grp URL: http://www.eccnet.com | http://www.eccnet.com/xmlug /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\\/\/ Member of XML Guild (www.xmlguild.org)
I take back my question - it is working perfectly -- unfortunately it is my brain that malfunctioned!!! Betty
I am having an issue getting conref to work in a virtual directory structure.
Using conref="../../mydirectory/filename.xml#id" doesn't work but when using the fully qualified path: conref="file:///K:/maindirectory/mydirectory/filename.xml#id" works perfectly.
Is there a trick to getting virtual directory structures working? It looks like Oxygen is looking on the C: drive gives the following error message:
Error while parsing external reference: 'file:/mydirectory/filename.xml#id. Cause: C:\mydirectory\filename.xml (The system cannot find the path specified)
I feel like this is probably a simple configuration in Oxygen.
TIA!
Betty
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Betty Harvey | Phone: 410-787-9200 FAX: 9830 Electronic Commerce Connection, Inc. | harvey@eccnet.com | Washington,DC XML Users Grp URL: http://www.eccnet.com | http://www.eccnet.com/xmlug /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\\/\/ Member of XML Guild (www.xmlguild.org) _______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Betty Harvey | Phone: 410-787-9200 FAX: 9830 Electronic Commerce Connection, Inc. | harvey@eccnet.com | Washington,DC XML Users Grp URL: http://www.eccnet.com | http://www.eccnet.com/xmlug /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\\/\/ Member of XML Guild (www.xmlguild.org)
I am trying to install a plugin on version 12.2. I am administrator. I noticed all the files were read only. I changed all the files to read/write. When I run the configuration to install the plugin I get the following errors on all the files. I have gone through the files to make sure I have privileges on the file: [integrate] java.io.FileNotFoundException: C:\Program Files (x86)\Oxygen XML Editor 12.2\frameworks\dita\DITA-OT\build_dita2eclipsehelp.xml (Access is denied) Does anyone know a solution to this problem? Betty /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Betty Harvey | Phone: 410-787-9200 FAX: 9830 Electronic Commerce Connection, Inc. | harvey@eccnet.com | Washington,DC XML Users Grp URL: http://www.eccnet.com | http://www.eccnet.com/xmlug /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\\/\/ Member of XML Guild (www.xmlguild.org)
Hello, In Windows Vista/7 you don't just need administrator rights for your user, you also need to run the application/installer as administrator to be able to write to system folders like "Program Files". In what form does the plugin installer come? If it's a windows executable(.exe) simply right click on it and from the contextual menu choose "Run as administrator". If it's a batch script(.bat, .cmd, ant), then first you should start a command prompt with administrator rights: All Programs -> Accesories -> right click on Command Prompt and from the contextual menu choose "Run as administrator". Then you can run the batch script from this command prompt. Regards, Adrian Adrian Buza oXygen XML Editor and Author Support support@oxygenxml.com http://www.oxygenxml.com Betty Harvey wrote:
I am trying to install a plugin on version 12.2. I am administrator. I noticed all the files were read only. I changed all the files to read/write. When I run the configuration to install the plugin I get the following errors on all the files. I have gone through the files to make sure I have privileges on the file:
[integrate] java.io.FileNotFoundException: C:\Program Files (x86)\Oxygen XML Editor 12.2\frameworks\dita\DITA-OT\build_dita2eclipsehelp.xml (Access is denied)
Does anyone know a solution to this problem?
Betty
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Betty Harvey | Phone: 410-787-9200 FAX: 9830 Electronic Commerce Connection, Inc. | harvey@eccnet.com | Washington,DC XML Users Grp URL: http://www.eccnet.com | http://www.eccnet.com/xmlug /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\\/\/ Member of XML Guild (www.xmlguild.org) _______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user
On Wed, September 29, 2010 10:05 am, George Cristian Bina wrote: ...
What I would like to have is an area on our website where people can post and share frameworks for different vocabularies. These should be also discoverable from oXygen so you can browse the available frameworks and decide to get some of them locally.
The XSpec framework for testing XSLT and XQuery has its own <oXygen/> framework. See http://code.google.com/p/xspec/ I did an OSIS framework for a client project, and I expect that could be made publicly available quite easily. Regards, Tony Graham Tony.Graham@MenteithConsulting.com Director W3C XSL FO SG Invited Expert Menteith Consulting Ltd XML Guild member XML, XSL and XSLT consulting, programming and training Registered Office: 13 Kelly's Bay Beach, Skerries, Co. Dublin, Ireland Registered in Ireland - No. 428599 http://www.menteithconsulting.com -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- xmlroff XSL Formatter http://xmlroff.org xslide Emacs mode http://www.menteith.com/wiki/xslide Unicode: A Primer urn:isbn:0-7645-4625-2
participants (7)
-
Adrian Buza -
Betty Harvey -
Eliot Kimber -
George Cristian Bina -
Syd Bauman -
Tony Graham -
Wendell Piez