- oXygen-user - www.oxygenxml.com

[ann] oXygen XML Editor 17
by George Bina 05 May '15

05 May '15

Hi all, I am happy to announce that the new oXygen XML Editor version 17 is generally available from our website: http://www.oxygenxml.com Thank you for your feedback on the beta version that we made available earlier, we were able to incorporate many of those ideas in the final oXygen 17 release. You can read the release notes with the new version highlight as well as details, screenshots and video presentations of some of the new features at: http://oxygenxml.com/whatisnew17.0.html We also plan a series of 6 webinars to present the new version, scheduled every Wednesday at 8 AM PDT / 11 AM EDT / 5 PM CEST so it will be great if you can join us to see the new functionality presented by our developers and get your questions asked in the Q&A section. To register just follow the links from our events page http://oxygenxml.com/events_programme.html Next month we will also attend XML London and in the pre-conference day we organize an oXygen users meetup where we will be happy to have you as guests - this is a free, full day event, but registration is required. Details on the meetup (agenda, registration form, location) are available here: http://oxygenxml.com/events/2015/oXygen-user-meetup-London.html Thank you again for your feedback on oXygen and enjoy using version 17! Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com

1 0

Re: [oXygen-user] Feature request: Improvement of Japanese search for WebHelp
by T. Hatanaka 30 Apr '15

30 Apr '15

Sorin, I tried it out and found the indexed terms improved as expected. Also confirmed that the user dictionary was loaded, which prevented the critical words from being missed. A simple but rather critical issue in the user experience at this moment: nwSearchFnt.js expects 3 or more characters, while the Japanese words usually consist of 2 or more characters. As a quick fix for testing purposes, I reduced the following threshold to 1 when indexerLanguage=='ja'. > if (finalArray[x].length > 2 || useCJKTokenizing){ > if (word.length > 2) { There are a few other minor things that could be improved; I'll report them in due course. The experience as a whole is very promising. Thank you so much! Thanks, T. Hatanaka -----Original Message----- From: oxygen-user-bounces(a)oxygenxml.com [mailto:oxygen-user-bounces@oxygenxml.com] On Behalf Of Support Oxygen XML Editor (Sorin Ristache) Sent: Thursday, April 30, 2015 3:15 PM To: T. Hatanaka; oXygen-user(a)oxygenxml.com Subject: Re: [oXygen-user] Feature request: Improvement of Japanese search for WebHelp Hi, Please test the search in WebHelp pages Japanese content with the following Oxygen 17.0 beta build: http://www.oxygenxml.com/userFiles/oxygen-AllPlatforms-17.0-beta-build-2015… You have to set the Japanese language in your DITA map (by adding the xml:lang="ja-jp" parameter) or in the args.default.language parameter and also follow the instructions at the end of the listing with DITA transformation output messages for adding the Kuromoji analyzer runtime file. After you add the runtime file the DITA transformation will detect it and call it to index the Japanese content. The search terms should be separated by spaces as in European languages but I think you already know that better than us because you are the one who suggested we can assume that for a Japanese search string entered in a web page. A Japanese user dictionary for the Kuromoji analyzer is optional and can be set in the webhelp.search.japanese.dictionary parameter. Best regards, Sorin <oXygen/> XML Editor http://www.oxygenxml.com On 4/30/2015 8:47 AM, T. Hatanaka wrote: > Super! > It'll be a great bonus to 17.0 whose beta itself is already amazing. > I'll definitely test it out as soon as released. > If I can help in any way at this moment, please let me know. > > Thanks, > T. Hatanaka > > -----Original Message----- > From: oxygen-user-bounces(a)oxygenxml.com [mailto:oxygen-user-bounces@oxygenxml.com] On Behalf Of Sorin Ristache > Sent: Tuesday, April 28, 2015 11:16 PM > To: T. Hatanaka; oXygen-user(a)oxygenxml.com > Subject: Re: [oXygen-user] Feature request: Improvement of Japanese search for WebHelp > > Hi, > > We implemented indexing of Japanese content in the WebHelp pages with > the Kuromoji analyzer. It will go in the upcoming Oxygen 17.0 release. > The Kuromoji analyzer will not be included in the Oxygen install kit, > but a detailed INFO message in the DITA transformation console view will > tell you where you can download the analyzer runtime file and where you > have to copy it in the Oxygen install directory in order to enable > indexing of Japanese content. > > Also a new parameter was added in the transformation for setting a user > dictionary to the Kuromoji analyzer. It is an optional parameter, so the > search results should be greatly improved on Japanese content even > without setting a user dictionary. > > > Regards, > Sorin > > <oXygen/> XML Editor > > http://www.oxygenxml.com > > > On 4/17/2015 2:34 PM, T. Hatanaka wrote: >> Thank you for hearing. >> Analyzer + user dic will be a huge plus in the relevant cultural area like us. _______________________________________________ oXygen-user mailing list oXygen-user(a)oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user

2 1

updated framework not used in conversion
by Lou Burnard 30 Apr '15

30 Apr '15

I'm puzzled... I have installed all the recent updates to the TEI framework from the TEI site, and my local .com.oxygen.xml directory contains an updated version of one of the XSLT scripts provided as a result: -rw-rw-r-- 1 lou lou 13520 Apr 29 12:02 ./.com.oxygenxml/extensions/v16.1/frameworks/http___www.tei_c.org_release_oxygen_updateSite.oxygen/tei/xml/tei/stylesheet/profiles/oulipo/from_common.xsl However, when I actually run the conversion from within oXygen, it does not use this version, but instead the one released ages ago, which is still in the installation directory: -rw-r--r-- 1 lou lou 9612 Jan 22 13:43 ./OxygenXMLEditor16/frameworks/tei/xml/tei/stylesheet/profiles/oulipo/from_common.xsl The Ant script I am running in my transformation says "Loading stylesheet /home/lou/OxygenXMLEditor16/frameworks/tei/xml/tei/stylesheet/profiles/oulipo/docx/from.xsl" It also uses the build-from.xml file from the same directory, rather than the one one in the .com.oxygml tree, which is however identical. But since it uses relative paths, maybe that is the problem? Any advice much appreciated...

2 3

Re: [oXygen-user] Feature request: Improvement of Japanese search for WebHelp
by T. Hatanaka 30 Apr '15

30 Apr '15

Super! It'll be a great bonus to 17.0 whose beta itself is already amazing. I'll definitely test it out as soon as released. If I can help in any way at this moment, please let me know. Thanks, T. Hatanaka -----Original Message----- From: oxygen-user-bounces(a)oxygenxml.com [mailto:oxygen-user-bounces@oxygenxml.com] On Behalf Of Sorin Ristache Sent: Tuesday, April 28, 2015 11:16 PM To: T. Hatanaka; oXygen-user(a)oxygenxml.com Subject: Re: [oXygen-user] Feature request: Improvement of Japanese search for WebHelp Hi, We implemented indexing of Japanese content in the WebHelp pages with the Kuromoji analyzer. It will go in the upcoming Oxygen 17.0 release. The Kuromoji analyzer will not be included in the Oxygen install kit, but a detailed INFO message in the DITA transformation console view will tell you where you can download the analyzer runtime file and where you have to copy it in the Oxygen install directory in order to enable indexing of Japanese content. Also a new parameter was added in the transformation for setting a user dictionary to the Kuromoji analyzer. It is an optional parameter, so the search results should be greatly improved on Japanese content even without setting a user dictionary. Regards, Sorin <oXygen/> XML Editor http://www.oxygenxml.com On 4/17/2015 2:34 PM, T. Hatanaka wrote: > Thank you for hearing. > Analyzer + user dic will be a huge plus in the relevant cultural area like us. _______________________________________________ oXygen-user mailing list oXygen-user(a)oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user

2 1

Oxygen 16.1 won't run with DITA OT 2.0.1
by Mark Giffin 29 Apr '15

29 Apr '15

I copied a standard DITA Map XHTML output scenario and pointed it at a copy of DITA OT 2.0.1. It fails with the following error. Similar error for PDF output. No other changes to the scenario. ---------------- BUILD FAILED C:\Users\Mark\dita-ots\DITA-OT2.0.1\build.xml:41: The following error occurred while executing this line: C:\Users\Mark\dita-ots\DITA-OT2.0.1\plugins\org.dita.base\build_preprocess.xml:78: Failed to run pipeline: URI has a query component ---------------- Does it not work this way? Full log below. Thanks, Mark ---------------------------- Executing: "c:\program files (x86)\oxygen xml editor 16\jre/bin/java" -Xmx384m "-Dorg.apache.xerces.xni.parser.XMLParserConfiguration=org.ditang.relaxng.defaults.RelaxDefaultsParserConfiguration" -classpath "C:\Program Files (x86)\Oxygen XML Editor 16\tools\ant/lib/ant-launcher.jar" "-Dant.home=C:\Program Files (x86)\Oxygen XML Editor 16\tools\ant" org.apache.tools.ant.launch.Launcher -lib "C:\Program Files (x86)\Oxygen XML Editor 16\classes" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\oxygen.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\oxygenAuthor.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\oxygenDeveloper.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\oxygenEclipse.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\oxygenAuthorEclipse.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\oxygenDeveloperEclipse.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\resolver.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\org.eclipse.wst.xml.xpath2.processor_1.2.0.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\xml-apis.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\xercesImpl.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\commons-io-1.3.1.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\commons-logging-1.1.3.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\log4j.jar" -lib "C:\Users\Mark\dita-ots\DITA-OT2.0.1\lib\commons-codec-1.4.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\jing.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\saxon9ee.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\saxon.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\xmlgraphics-commons-1.5.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\fop.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\batik-all-1.7.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\js.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\xml-apis-ext.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\avalon-framework-4.2.0.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\jeuclid-core.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\jeuclid-fop.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\jai_tiff.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\jh.jar" -lib "C:\Users\Mark\dita-ots\DITA-OT2.0.1\lib\jsearch.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\lucene-analyzers-common-4.0.0.jar" -lib "C:\Program Files (x86)\Oxygen XML Editor 16\lib\lucene-core-4.0.0.jar" -lib "C:\Users\Mark\dita-ots\DITA-OT2.0.1\plugins\com.oxygenxml.webhelp\lib\xhtml-indexer.jar" -lib "C:\Users\Mark\dita-ots\DITA-OT2.0.1\plugins\com.oxygenxml.highlight\lib\xslthl-2.1.1.jar" -lib "C:\Users\Mark\dita-ots\DITA-OT2.0.1" -lib "C:\Users\Mark\dita-ots\DITA-OT2.0.1\lib\dost-patches.jar" -lib "C:\Users\Mark\dita-ots\DITA-OT2.0.1\lib" -lib "C:\Users\Mark\dita-ots\DITA-OT2.0.1\lib\dost.jar" -f "C:\Users\Mark\dita-ots\DITA-OT2.0.1/build.xml" "-Dtranstype=pdf2" "-Dbasedir=C:\Users\Mark\Desktop\Security Guide" "-Doutput.dir=C:\Users\Mark\Desktop\Security Guide/out/pdf" "-Ddita.temp.dir=C:\Users\Mark\Desktop\Security Guide/temp/pdf" "-Dpdf.formatter=fop" "-Dxep.failOnError=true" "-Ddita.dir=C:\Users\Mark\dita-ots\DITA-OT2.0.1" "-Dargs.input=C:\Users\Mark\Desktop\Security Guide\Security-Guide.ditamap" "-DbaseJVMArgLine=-Xmx384m" Buildfile: C:\Users\Mark\dita-ots\DITA-OT2.0.1\build.xml init: dita2pdf2.init: check-arg: [mkdir] Created dir: C:\Users\Mark\Desktop\Security Guide\temp\pdf log-arg: [echo] ***************************************************************** [echo] * basedir = C:\Users\Mark\Desktop\Security Guide [echo] * dita.dir = C:\Users\Mark\dita-ots\DITA-OT2.0.1 [echo] * transtype = pdf2 [echo] * tempdir = C:\Users\Mark\Desktop\Security Guide/temp/pdf [echo] * outputdir = C:\Users\Mark\Desktop\Security Guide/out/pdf [echo] * clean.temp = true [echo] * DITA-OT version = 2.0.1 [echo] * XML parser = Xerces [echo] * XSLT processor = Saxon [echo] * collator = ICU [echo] ***************************************************************** [echo] #Ant properties [echo] #Tue Apr 28 21:26:10 PDT 2015 [echo] args.grammar.cache=yes [echo] args.input=C\:\\Users\\Mark\\Desktop\\Security Guide\\Security-Guide.ditamap [echo] args.logdir=C\:\\Users\\Mark\\Desktop\\Security Guide/out/pdf [echo] args.rellinks=nofamily [echo] args.xml.systemid.set=yes [echo] dita.dir=C\:\\Users\\Mark\\dita-ots\\DITA-OT2.0.1 [echo] dita.plugin.com.sophos.tocjs.dir=C\:\\Users\\Mark\\dita-ots\\DITA-OT2.0.1\\plugins\\com.sophos.tocjs [echo] dita.plugin.org.dita.base.dir=C\:\\Users\\Mark\\dita-ots\\DITA-OT2.0.1 [echo] dita.plugin.org.dita.docbook.dir=C\:\\Users\\Mark\\dita-ots\\DITA-OT2.0.1\\plugins\\org.dita.docbook [echo] dita.plugin.org.dita.eclipsecontent.dir=C\:\\Users\\Mark\\dita-ots\\DITA-OT2.0.1\\plugins\\org.dita.eclipsecontent [echo] dita.plugin.org.dita.eclipsehelp.dir=C\:\\Users\\Mark\\dita-ots\\DITA-OT2.0.1\\plugins\\org.dita.eclipsehelp [echo] dita.plugin.org.dita.htmlhelp.dir=C\:\\Users\\Mark\\dita-ots\\DITA-OT2.0.1\\plugins\\org.dita.htmlhelp [echo] dita.plugin.org.dita.javahelp.dir=C\:\\Users\\Mark\\dita-ots\\DITA-OT2.0.1\\plugins\\org.dita.javahelp [echo] dita.plugin.org.dita.odt.dir=C\:\\Users\\Mark\\dita-ots\\DITA-OT2.0.1\\plugins\\org.dita.odt [echo] dita.plugin.org.dita.pdf2.dir=C\:\\Users\\Mark\\dita-ots\\DITA-OT2.0.1\\plugins\\org.dita.pdf2 [echo] dita.plugin.org.dita.specialization.dita11.dir=C\:\\Users\\Mark\\dita-ots\\DITA-OT2.0.1\\plugins\\org.dita.specialization.dita11 [echo] dita.plugin.org.dita.specialization.dita132.dir=C\:\\Users\\Mark\\dita-ots\\DITA-OT2.0.1\\plugins\\org.dita.specialization.dita132 [echo] dita.plugin.org.dita.specialization.eclipsemap.dir=C\:\\Users\\Mark\\dita-ots\\DITA-OT2.0.1\\plugins\\org.dita.specialization.eclipsemap [echo] dita.plugin.org.dita.troff.dir=C\:\\Users\\Mark\\dita-ots\\DITA-OT2.0.1\\plugins\\org.dita.troff [echo] dita.plugin.org.dita.wordrtf.dir=C\:\\Users\\Mark\\dita-ots\\DITA-OT2.0.1\\plugins\\org.dita.wordrtf [echo] dita.plugin.org.dita.xhtml.dir=C\:\\Users\\Mark\\dita-ots\\DITA-OT2.0.1\\plugins\\org.dita.xhtml [echo] dita.plugin.org.oasis-open.dita.v1_2.dir=C\:\\Users\\Mark\\dita-ots\\DITA-OT2.0.1\\plugins\\org.oasis-open.dita.v1_2 [echo] dita.temp.dir=C\:\\Users\\Mark\\Desktop\\Security Guide/temp/pdf [echo] preprocess.copy-image.skip=true [echo] ***************************************************************** build-init: preprocess.init: [echo] ***************************************************************** [echo] * input = C:\Users\Mark\Desktop\Security Guide\Security-Guide.ditamap [echo] ***************************************************************** gen-list: [gen-list] Using Xerces grammar pool for DTD and schema caching. [gen-list] Processing file:/C:/Users/Mark/Desktop/Security%20Guide/Security-Guide.ditamap [gen-list] Processing file:/C:/Users/Mark/Desktop/Security%20Guide/SecurityOverview.ditamap [gen-list] Processing file:/C:/Users/Mark/Desktop/Security%20Guide/SecurityArchitecture.ditamap [gen-list] Processing file:/C:/Users/Mark/Desktop/Security%20Guide/TheglellloginUtility.ditamap [gen-list] Processing file:/C:/Users/Mark/Desktop/Security%20Guide/TicketsandCertificates.ditamap [gen-list] Processing file:/C:/Users/Mark/Desktop/Security%20Guide/ConfiguringglellSecurity.ditamap ... deleted ... [gen-list] Processing file:/C:/Users/Mark/Desktop/Security%20Guide/ConfiguringaglellClusterto_26281156-d3e460.dita [gen-list] Processing file:/C:/Users/Mark/Desktop/Security%20Guide/ConfiguringaglellClusterto_26281156-d3e497.dita [gen-list] Processing file:/C:/Users/Mark/Desktop/Security%20Guide/ConfiguringaglellClusterto_26281156-d3e550.dita [gen-list] Processing file:/C:/Users/Mark/Desktop/Security%20Guide/ConfiguringaglellClusterto_26281156-d3e560.dita BUILD FAILED C:\Users\Mark\dita-ots\DITA-OT2.0.1\build.xml:41: The following error occurred while executing this line: C:\Users\Mark\dita-ots\DITA-OT2.0.1\plugins\org.dita.base\build_preprocess.xml:78: Failed to run pipeline: URI has a query component Total time: 1 second The process finished with exit code: 1

2 1

Re: [oXygen-user] Feature request: Improvement of Japanese search for WebHelp
by T. Hatanaka 28 Apr '15

28 Apr '15

Thank you for hearing. Analyzer + user dic will be a huge plus in the relevant cultural area like us. -----Original Message----- From: oxygen-user-bounces(a)oxygenxml.com [mailto:oxygen-user-bounces@oxygenxml.com] On Behalf Of Support Oxygen XML Editor (Sorin Ristache) Sent: Thursday, April 16, 2015 7:07 PM To: T. Hatanaka; oXygen-user(a)oxygenxml.com Subject: Re: [oXygen-user] Feature request: Improvement of Japanese search for WebHelp Hi, I did some research on the user dictionaries and my understanding is that setting a user dictionary is a great enhancement for morphological Lucene analyzers like the ones for the CJK languages, for example the JapaneseAnalyzer, and also for indexing domain-specific content in any language. So we should add a new parameter to the WebHelp page generation process for setting a user dictionary which makes sense for any language of the page content. The user dictionary has a simple and direct use for a morphological analyzer like the JapaneseAnalyzer because it is just a parameter of the class constructor, but is a little more complicated to integrate into the sequence of Lucene filters that follows an initial Lucene tokenizer in the typical Lucene processing pipeline for non-CJK languages. Thank you for your suggestions, Sorin <oXygen/> XML Editor http://www.oxygenxml.com On 4/15/2015 6:13 PM, T. Hatanaka wrote: > Hi, > >> What would the custom Japanese user dictionary add to the build-time >> indexing process: >> >> - a list of domain-specific words > > It will be the most important. > >> - or some generic tweaks that would allow matching a client-side search > > Presumably it will be JavaScript's role just as its wordsStartsWith() (I guess) does currently. > >> the generic tweaks added by a custom user >> dictionary would not be needed anymore. Could you give a short example >> please? > > Suppose there is a Japanese sentence whose structure resembles "OVERPAYPALEBAYBERRY." > > Kuromoji or any analyzer may segment it as "over,paypal,ebay,berry", "overpay,pale,bayberry", "over,pay,pal,e,bay,berry" or so, depending on its built-in dictionary and method. There is no single authoritative answer. > > With one of such imperfect indexes, the user may search for 'over', 'overpay', 'paypal', 'pale', 'ale', 'ebay', 'bay', 'bayberry', 'verpaypalebaybe' or even 'e'... (The last two may look ridiculous, but such array of characters can be a self-contained atomic well-known word in the Japanese language.) > > Kuromoji is clever enough to return multiple terms such as "(paypal|pay,pal),(ebay|e,bay)", but that would never be perfect. Hence the user dictionary can play a critical role to let the analyzer know the novel word "verpaypalebaybe" or boost the priority of "ale". > > Thanks, > T. Hatanaka > ________________________________________ > From: oxygen-user-bounces(a)oxygenxml.com <oxygen-user-bounces(a)oxygenxml.com> on behalf of Support Oxygen XML Editor (Sorin Ristache) <support(a)oxygenxml.com> > Sent: Wednesday, April 15, 2015 21:14 > To: T. Hatanaka; oXygen-user(a)oxygenxml.com > Subject: Re: [oXygen-user] Feature request: Improvement of Japanese search for WebHelp > > Hello, > > Thank you for telling us, we will try to integrate the Kuromoji > analyzer into the Apache Lucene system that indexes the WebHelp pages. > > What would the custom Japanese user dictionary add to the build-time > indexing process: > > - a list of domain-specific words that are relevant for the domain of > the current DITA map and that are missing in the generic dictionary that > comes with the Kuromoji analyzer, > > - or some generic tweaks that would allow matching a client-side search > term with a partial match in the index built based on the WebHelp pages? > > I thought Kuromoji was a morphological analyzer that builds the index so > that a client-side search term will be matched with an indexed term > picked up from a WebHelp page even though the indexed term is only a > partial match, which means the generic tweaks added by a custom user > dictionary would not be needed anymore. Could you give a short example > please? > > > Thank you, > Sorin > > <oXygen/> XML Editor > > http://www.oxygenxml.com _______________________________________________ oXygen-user mailing list oXygen-user(a)oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user

2 1

Re: [oXygen-user] Use BaseX for XQuery Validation?
by Lizzi, Vincent 22 Apr '15

22 Apr '15

I have been wanting better support for BaseX in oXygen too. Being able to run XQuery on BaseX from within oXygen (via XQJ) is very useful. The guided editing and validation in oXygen (for example for XSLT) is extremely useful. It would be great to have both together in oXygen. Currently I switch to the BaseX GUI to write XQuery for BaseX, but this is not always practical because the BaseX GUI works only with local databases. Thanks, Vincent -----Original Message----- Message: 4 Date: Fri, 17 Apr 2015 08:48:33 -0500 From: Eliot Kimber <ekimber(a)contrext.com> To: Oxygen User <oxygen-user(a)oxygenxml.com> Subject: [oXygen-user] Use BaseX for XQuery Validation? Message-ID: <D1567960.527D4%ekimber(a)contrext.com> Content-Type: text/plain; charset="UTF-8" I'm implementing BaseX-specific XQueries, which use BaseX's support for importing modules based on mapping module URIs to a specific installation folder. Thus the XQuery processing has to go through the BaseX server code that provides the module resolution. Is there a way to configure BaseX as an XQuery validator in this case? I set up a BaseX validator but it fails to validate my BaseX-specific XQuery module with a "fails static validation" error, which I assume is because it can't resolve the modules. Thanks, Eliot ????? Eliot Kimber, Owner Contrext, LLC http://contrext.com ------------------------------ Message: 5 Date: Fri, 17 Apr 2015 18:01:51 +0300 From: "Oxygen XML Editor Support (Adrian Buza)" <support(a)oxygenxml.com> To: oxygen-user(a)oxygenxml.com Subject: Re: [oXygen-user] Use BaseX for XQuery Validation? Message-ID: <5531205F.6080601(a)oxygenxml.com> Content-Type: text/plain; charset=utf-8; format=flowed Hello Eliot, While it's possible to use an XQJ implementation/connection (like BaseX) for XQuery validation in Oxygen, it's a simple pass/fail validation, with no real details about the errors or their location, so not very useful. Regards, Adrian Adrian Buza oXygen XML Editor and Author Support Tel: +1-650-352-1250 ext.2020 Fax: +40-251-461482 support(a)oxygenxml.com http://www.oxygenxml.com On 17.04.2015 16:48, Eliot Kimber wrote: > I'm implementing BaseX-specific XQueries, which use BaseX's support > for importing modules based on mapping module URIs to a specific > installation folder. Thus the XQuery processing has to go through the > BaseX server code that provides the module resolution. > > Is there a way to configure BaseX as an XQuery validator in this case? > > I set up a BaseX validator but it fails to validate my BaseX-specific > XQuery module with a "fails static validation" error, which I assume > is because it can't resolve the modules. > > Thanks, > > Eliot > ????? > Eliot Kimber, Owner > Contrext, LLC > http://contrext.com > > > > _______________________________________________ > oXygen-user mailing list > oXygen-user(a)oxygenxml.com > http://www.oxygenxml.com/mailman/listinfo/oxygen-user ------------------------------ _______________________________________________ oXygen-user mailing list oXygen-user(a)oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user End of oXygen-user Digest, Vol 54, Issue 11 *******************************************

2 1

document validation
by Roderik Dernison 21 Apr '15

21 Apr '15

Good morning, I've made an extension to the DITA-schema called ling and another extension called ling-sod. The first validates fine. But the second gives errors: Description: cos-nonambig: emphasis and emphasis (or elements from their substitution group) violate "Unique Particle Attribution". During validation against this schema, ambiguity would be created for those two particles. However, when I click the error message I'm redirected to another element that doesn't seem to be related to the problem. How to solve this problem? Vriendelijke groet, Ing. Roderik Dernison Programmeur/ontwikkelaar INL * Schatkamer van de Nederlandse Taal Matthias de Vrieshof 2 * Kamer 106a * 2311 BZ Leiden Tel. +31 (0)71 527 2491 * www.inl.nl<http://www.inl.nl/> ________________________________ ---------------------------------------------------------- Aan dit bericht kunnen geen rechten worden ontleend. Het bericht is alleen bestemd voor de geadresseerde. Indien het bericht niet voor u is bestemd, verzoeken wij u dit aan ons te melden en het bericht te verwijderen. This message shall not constitute any obligations. This message is intended solely for the addressee. If you have received this message in error, please inform us and delete the message. ----------------------------------------------------------

2 1

blank context pane
by Bob Stayton 20 Apr '15

20 Apr '15

I've been using Oxygen XML for years to debug XSL stylesheets. In the latest versions, the window pane for the context element has shown odd behavior. When I step through the debug process, the Context pane flashes the context element, and then clears immediately. If I'm quick, I can almost read it. Is there some autoclear function that I'm not aware of for that pane? The Variables and other panes are working fine. -- Bob Stayton Sagehill Enterprises bobs(a)sagehill.net

2 1

Use BaseX for XQuery Validation?
by Eliot Kimber 17 Apr '15

17 Apr '15

I'm implementing BaseX-specific XQueries, which use BaseX's support for importing modules based on mapping module URIs to a specific installation folder. Thus the XQuery processing has to go through the BaseX server code that provides the module resolution. Is there a way to configure BaseX as an XQuery validator in this case? I set up a BaseX validator but it fails to validate my BaseX-specific XQuery module with a "fails static validation" error, which I assume is because it can't resolve the modules. Thanks, Eliot ————— Eliot Kimber, Owner Contrext, LLC http://contrext.com

2 1

Overline style
by Joel 17 Apr '15

17 Apr '15

Hello, How do I apply an overline style in Oxygen? I have electronic symbols that need a line above the text. Thanks, Joel

2 1

[Ann] Oxygen XML Editor 17.0 beta - build 2015041612
by Oxygen XML Editor Support (Adrian Buza) 16 Apr '15

16 Apr '15

Dear oXygen users, We are happy to announce that version 17.0 of oXygen XML Editor is close to being released. We have decided to offer a new beta build (2015041612) prior to the final release to give you the opportunity to send us your feedback on the new features. Below, please see information about: * Downloading - oXygen 17.0 beta downloading links and notes * Licensing - a trial license key for testing * What's new - a summary of the most important new features in version 17.0 = Downloading = Windows 64-bit: http://www.oxygenxml.com/beta17/Windows64/oxygen-64bit.exe Windows 32-bit: http://www.oxygenxml.com/beta17/Windows/oxygen.exe OS X/Java SE 6: http://www.oxygenxml.com/beta17/MacOSX/oxygen.zip Linux 64-bit: http://www.oxygenxml.com/beta17/Linux64/oxygen-64bit.sh Linux/All Platforms: http://www.oxygenxml.com/beta17/All/oxygen.tar.gz Eclipse/ZIP: http://www.oxygenxml.com/beta17/Eclipse/com.oxygenxml.editor_17.0.0.v201504… Important Notes: - This build is meant for testing purposes only. Do not use it for production work. - You should install this beta version in a different directory than your current Oxygen installation. For Windows, we also recommend that you disable file associations during the installation to preserve your current Oxygen file associations with the various XML file types. - The OS X .zip distribution requires Java SE 6 from Apple, which is available here: http://support.apple.com/kb/DL1572 - For 32-bit Linux you have to use the "All Platforms" distribution and you also need to have installed either OpenJDK 7 (http://openjdk.java.net/install/) or Java SE 8 JRE/JDK from Oracle (http://www.oracle.com/technetwork/java/javase/downloads/index.html) - The "All Platforms" (.tar.gz) distribution includes launchers for Mac (Oxygen XML Editor.app or oxygenMac.sh), Linux (oxygen.sh), and Windows (oxygen.bat). - All feedback is welcome. = Licensing = If you already have a license key for Oxygen XML Editor with an active SMP, it will also work for this beta version. If you don't have one, a registration dialog box will open and you can use the following trial license key: ------START-LICENSE-KEY------ Registration_Name=oXygen XML v17 Beta Company= Category=Enterprise Component=XML-Editor, XSLT-Debugger, Saxon-SA Version=17 Number_of_Licenses=1 Date=03-30-2015 Trial=31 SGN=MCwCFADtFJ2DUmrsYwVq4sDUfqegwtpdAhRZLID8yK5+0R+UxlPRnLQ9fxCMFQ\=\= -------END-LICENSE-KEY------- = What's new in Oxygen XML Editor 17.0 = XML Quick Fixes: * Quick Fixes for Relax NG Errors * Schematron Quick Fixes XML Refactoring: * XML Refactoring Tool Visual XML Editing: * LESS Support in the Author Mode * Change the Tag Display Font * Actions to Insert Multiple Rows or Columns * The fileFilter Property is Available for URLChooser Form Control * Bold, Italic, and Underline Actions Support Multiple Selections Interface: * Customizable Toolbars * Color Themes * Improved HiDPI and Retina Support * Online Help Option DITA Support: * Search for Orphaned Resources Not Referenced in DITA Maps * Insert Image Reference Wizard * Validation Warning for References to Missing Topics and Images * Publish DITA Maps to Web Presentations * Auto-Detect Transformation Types and Parameters for Newly Installed DITA OT Plugins * CSS Improvements * DITA Map CSS Can Render Subject Scheme Map Elements * Support for DITA OT 2.0 * Check for Duplicate Topic IDs in a DITA Map WebHelp: * WebHelp Output Embeddable in iframe Element * WebHelp Context-Sensitive Help System * WebHelp System Supports LDAP Authentication * WebHelp System Supports Right-to-Left (RTL) Oriented Languages * Search Engine Optimization for WebHelp Output CSS: * CSS Inspector View * Support for Selecting/Combining Multiple CSS Styles in Author Mode * Support for editing LESS Stylesheets * Code Templates Included in the Content Completion List for Form Control Functions * New HTML Content Form Control * Define Actions for Button and Button Group Form Controls Directly in the CSS * Additional Properties Supported for the oxygen Media Type * The min-width and max-width Properties Supported for the CSS @media Rule * The font-family Property is Fully Supported * Support for position Property * Support for min-height Property * Support for letter-spacing Property * oxy_url Function with Editor Variables SVN Client: * Improvements to the Create Patch and Export Actions * Action to Display Additional Information About Versioned Items * Additional Improvements and Bug Fixes API: * Intercept List of Actions Provided by a Callout * Tree Component for Consistent Look and Feel * Customize Author Menu [Eclipse] * Customize Text/Author Contextual Menus [Eclipse] * Customize the Toolbars in the DITA Maps Manager [Eclipse] * Add Custom Browse Actions to Input Dialogs [Eclipse] * API for Customizing the Author Toolbar [Eclipse] * API for Providing Editor Adapters [Eclipse] * Plugin Extension to Specify Location of Custom Refactoring Operations * Styles Filter Extension Point [Eclipse] * ExtensionsBundle Extension Point [Eclipse] * Provide Text for a DITA Link [Eclipse] * Expand/Collapse Foldable Elements in Author Mode * Customize Drop-Down Buttons on a Toolbar [Eclipse] * Easier Way to Provide Documentation for Elements * Filter Errors Presented to the End User * Choose the Custom CSS to be Included in the Styles Drop-down List * Support for Composite Toolbars * API to Find Tracked Attribute Changes * Obtain a Reader Object of a URL Other: * Support for Configuring Proposals in the Content Completion Assistant * Ready for MarkLogic 8 * Automatic Escaping of Characters that Exceed the XML Encoding * Option to Lock Local Resources * Support for the JATS Document Type * Support for XLIFF 1.2 and 2.0 Documents * Compare Files Tool Includes Support for XML Fragment Comparison * Deprecated Support for Documentum CMS * Define Shortcut Keys for Code Templates Component Updates: * Apache HTTP Client 4.3.5 * Calabash 1.0.25 * eXist DB 2.2 * JSch 0.1.51 * Eclipse 4.5 Please let us know if you encounter any problems with this build. Again, all feedback is welcome. Best regards, Adrian -- Adrian Buza oXygen XML Editor and Author Support Tel: +1-650-352-1250 ext.2020 Fax: +40-251-461482 support(a)oxygenxml.com http://www.oxygenxml.com

1 0

Re: [oXygen-user] Feature request: Improvement of Japanese search for WebHelp
by T. Hatanaka 16 Apr '15

16 Apr '15

Hi, > What would the custom Japanese user dictionary add to the build-time > indexing process: > > - a list of domain-specific words It will be the most important. > - or some generic tweaks that would allow matching a client-side search Presumably it will be JavaScript's role just as its wordsStartsWith() (I guess) does currently. > the generic tweaks added by a custom user > dictionary would not be needed anymore. Could you give a short example > please? Suppose there is a Japanese sentence whose structure resembles "OVERPAYPALEBAYBERRY." Kuromoji or any analyzer may segment it as "over,paypal,ebay,berry", "overpay,pale,bayberry", "over,pay,pal,e,bay,berry" or so, depending on its built-in dictionary and method. There is no single authoritative answer. With one of such imperfect indexes, the user may search for 'over', 'overpay', 'paypal', 'pale', 'ale', 'ebay', 'bay', 'bayberry', 'verpaypalebaybe' or even 'e'... (The last two may look ridiculous, but such array of characters can be a self-contained atomic well-known word in the Japanese language.) Kuromoji is clever enough to return multiple terms such as "(paypal|pay,pal),(ebay|e,bay)", but that would never be perfect. Hence the user dictionary can play a critical role to let the analyzer know the novel word "verpaypalebaybe" or boost the priority of "ale". Thanks, T. Hatanaka ________________________________________ From: oxygen-user-bounces(a)oxygenxml.com <oxygen-user-bounces(a)oxygenxml.com> on behalf of Support Oxygen XML Editor (Sorin Ristache) <support(a)oxygenxml.com> Sent: Wednesday, April 15, 2015 21:14 To: T. Hatanaka; oXygen-user(a)oxygenxml.com Subject: Re: [oXygen-user] Feature request: Improvement of Japanese search for WebHelp Hello, Thank you for telling us, we will try to integrate the Kuromoji analyzer into the Apache Lucene system that indexes the WebHelp pages. What would the custom Japanese user dictionary add to the build-time indexing process: - a list of domain-specific words that are relevant for the domain of the current DITA map and that are missing in the generic dictionary that comes with the Kuromoji analyzer, - or some generic tweaks that would allow matching a client-side search term with a partial match in the index built based on the WebHelp pages? I thought Kuromoji was a morphological analyzer that builds the index so that a client-side search term will be matched with an indexed term picked up from a WebHelp page even though the indexed term is only a partial match, which means the generic tweaks added by a custom user dictionary would not be needed anymore. Could you give a short example please? Thank you, Sorin <oXygen/> XML Editor http://www.oxygenxml.com On 4/15/2015 2:19 PM, T. Hatanaka wrote: > Sorin, > > That will be of great help! > When you have a test or experimental build in the future, let me know and I'll be happy to test it, though I'm no expert. > > In the meantime, I took a look at the result of the following Lucene/Kuromoji code with Japanese inputs. > > UserDictionary userDic = new UserDictionary( new FileReader( new File( "userdic.txt" ) ) ); > Analyzer analyzer = new JapaneseAnalyzer( userDic, JapaneseTokenizer.Mode.SEARCH, > JapaneseAnalyzer.getDefaultStopSet(), JapaneseAnalyzer.getDefaultStopTags() ); > > These default parameters work fairly well even without UserDictionary(). > However, the user dictionary at build-time would be a strong plus, considering that the current client-side JavaScript would miss critical keywords due to its little tweak for partial match. > So, in your future design time, please also consider making the UserDictionary() file path configurable via a WebHelp transformation parameter. > > > Thanks, > T. Hatanaka > > ________________________________________ > From: oxygen-user-bounces(a)oxygenxml.com <oxygen-user-bounces(a)oxygenxml.com> on behalf of Support Oxygen XML Editor (Sorin Ristache) <support(a)oxygenxml.com> > Sent: Wednesday, April 15, 2015 00:17 > To: T. Hatanaka; oXygen-user(a)oxygenxml.com > Subject: Re: [oXygen-user] Feature request: Improvement of Japanese search for WebHelp > > Hello, > > > On 4/12/2015 5:26 AM, T. Hatanaka wrote: >> That being said, it would still benefit a lot to integrate sophisticated analyzers, even if it's only at build-time. Run-time ones are less required, I guess. When the Japanese people search Web, they, human beings, usually perform a kind of tokenization and normalization by themselves. >> i.e. They do not usually enter "BROWNFOXJUMPS" in the search text box. In most cases we can expect them to type "BROWN FOX JUMP". >> Actually "Please enter keywords separated by spaces" has been a common instruction found on the Japanese search UI. People have got used to it. >> So I guess that if the index were created by a sophisticated analyzer at build-time with custom dictionaries, we could improve search experience a lot with relatively minor tweaks in run-time JavaScript. > > > Thank you for letting us know. In a future version we will integrate the > Kuromoji analyzer in our Apache Lucene customization that runs on the > generated WebHelp pages for building the WebHelp search index. This > index will offer relevant search result in the WebHelp pages only for > Japanese search terms entered in the browser that are properly separated > with space characters. > > >> Here's another piece of news: >> Kuromoji has been ported to JavaScript: https://github.com/takuyaa/kuromoji.js >> I haven't tried it, but expect some difficulties. I heard it required a 17MB dictionary. > > > That is too large for a client-side JavaScript operation. The > tokenization of the search string entered by the user may take forever > based on a 17 MB JavaScript dictionary. The search will rely on properly > separated search terms entered by the user, as you suggested above. > > >> Thanks, >> T. Hatanaka > > > Best regards, > Sorin > > <oXygen/> XML Editor > > http://www.oxygenxml.com > _______________________________________________ > oXygen-user mailing list > oXygen-user(a)oxygenxml.com > http://www.oxygenxml.com/mailman/listinfo/oxygen-user > > > _______________________________________________ > oXygen-user mailing list > oXygen-user(a)oxygenxml.com > http://www.oxygenxml.com/mailman/listinfo/oxygen-user > _______________________________________________ oXygen-user mailing list oXygen-user(a)oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user

2 1

Re: [oXygen-user] Feature request: Improvement of Japanese search for WebHelp
by T. Hatanaka 15 Apr '15

15 Apr '15

Sorin, That will be of great help! When you have a test or experimental build in the future, let me know and I'll be happy to test it, though I'm no expert. In the meantime, I took a look at the result of the following Lucene/Kuromoji code with Japanese inputs. UserDictionary userDic = new UserDictionary( new FileReader( new File( "userdic.txt" ) ) ); Analyzer analyzer = new JapaneseAnalyzer( userDic, JapaneseTokenizer.Mode.SEARCH, JapaneseAnalyzer.getDefaultStopSet(), JapaneseAnalyzer.getDefaultStopTags() ); These default parameters work fairly well even without UserDictionary(). However, the user dictionary at build-time would be a strong plus, considering that the current client-side JavaScript would miss critical keywords due to its little tweak for partial match. So, in your future design time, please also consider making the UserDictionary() file path configurable via a WebHelp transformation parameter. Thanks, T. Hatanaka ________________________________________ From: oxygen-user-bounces(a)oxygenxml.com <oxygen-user-bounces(a)oxygenxml.com> on behalf of Support Oxygen XML Editor (Sorin Ristache) <support(a)oxygenxml.com> Sent: Wednesday, April 15, 2015 00:17 To: T. Hatanaka; oXygen-user(a)oxygenxml.com Subject: Re: [oXygen-user] Feature request: Improvement of Japanese search for WebHelp Hello, On 4/12/2015 5:26 AM, T. Hatanaka wrote: > That being said, it would still benefit a lot to integrate sophisticated analyzers, even if it's only at build-time. Run-time ones are less required, I guess. When the Japanese people search Web, they, human beings, usually perform a kind of tokenization and normalization by themselves. > i.e. They do not usually enter "BROWNFOXJUMPS" in the search text box. In most cases we can expect them to type "BROWN FOX JUMP". > Actually "Please enter keywords separated by spaces" has been a common instruction found on the Japanese search UI. People have got used to it. > So I guess that if the index were created by a sophisticated analyzer at build-time with custom dictionaries, we could improve search experience a lot with relatively minor tweaks in run-time JavaScript. Thank you for letting us know. In a future version we will integrate the Kuromoji analyzer in our Apache Lucene customization that runs on the generated WebHelp pages for building the WebHelp search index. This index will offer relevant search result in the WebHelp pages only for Japanese search terms entered in the browser that are properly separated with space characters. > Here's another piece of news: > Kuromoji has been ported to JavaScript: https://github.com/takuyaa/kuromoji.js > I haven't tried it, but expect some difficulties. I heard it required a 17MB dictionary. That is too large for a client-side JavaScript operation. The tokenization of the search string entered by the user may take forever based on a 17 MB JavaScript dictionary. The search will rely on properly separated search terms entered by the user, as you suggested above. > Thanks, > T. Hatanaka Best regards, Sorin <oXygen/> XML Editor http://www.oxygenxml.com _______________________________________________ oXygen-user mailing list oXygen-user(a)oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user

2 1

Generating IDs on DITA maps
by Mark Giffin 15 Apr '15

15 Apr '15

Is there a way to get Oxygen to generate an ID for a new DITA map? It already does this for topics. Also, is there a way to batch generate IDs for a whole group of XML files, like those in a DITA map? I see info on things like "Managing ID/IDREFS" in the help, but that seems to apply to something else. Thanks, Mark

2 3

Re: [oXygen-user] Feature request: Improvement of Japanese search for WebHelp
by T. Hatanaka 14 Apr '15

14 Apr '15

Let me revive this old thread. Could you reconsider this? As already said, the Japanese text has no explicit word breakers. It's something like "THEQUICKBROWNFOXJUMPSOVERTHELAZYDOG." The current WebHelp implementation is tokenizing it into "TH" "HE" "EQ" "QU" "UI" "IC" "CK"... both at build-time and run-time. It works to some extent, but not quite comfortable. That's why analyzers such as Kuromoji are most welcome. And, to deliver fully capable search experience, WebHelp requires both build-time and run-time analyzers, as you pointed out. That being said, it would still benefit a lot to integrate sophisticated analyzers, even if it's only at build-time. Run-time ones are less required, I guess. When the Japanese people search Web, they, human beings, usually perform a kind of tokenization and normalization by themselves. i.e. They do not usually enter "BROWNFOXJUMPS" in the search text box. In most cases we can expect them to type "BROWN FOX JUMP". Actually "Please enter keywords separated by spaces" has been a common instruction found on the Japanese search UI. People have got used to it. So I guess that if the index were created by a sophisticated analyzer at build-time with custom dictionaries, we could improve search experience a lot with relatively minor tweaks in run-time JavaScript. Here's another piece of news: Kuromoji has been ported to JavaScript: https://github.com/takuyaa/kuromoji.js I haven't tried it, but expect some difficulties. I heard it required a 17MB dictionary. Thanks, T. Hatanaka -----Original Message----- From: oxygen-user-bounces(a)oxygenxml.com [mailto:oxygen-user-bounces@oxygenxml.com] On Behalf Of Sorin Ristache Sent: Tuesday, November 19, 2013 6:09 PM To: Naoki Hirai Cc: oXygen-user(a)oxygenxml.com Subject: Re: [oXygen-user] Feature request: Improvement of Japanese search for WebHelp Dear Naoki-san, The Webhelp content indexer is indeed based on the Lucene engine just like the Kuromoji morphological analyzer, so delegating the task of indexing any Japanese content at build time (when the Webhelp pages are created by the Oxygen Webhelp transformation) to the Kuromoji analyzer is doable. However the Webhelp search is performed at runtime on the client side, with JavaScript code running on the machine where the Webhelp search is executed in the browser, not on the server side, where the Webhelp pages are stored. The difficulty in integrating an analyzer that deals with a specific language sentence morphology like the Kuromoji analyzer comes from the lack of an equivalent JavaScript analyzer that is able to split the search string entered by the user into the morphological components recognized by the Lucene-based morphological analyzer that built the index database at build time. I did a Google search but I could not identify a client side JavaScript solution for a Japanese morphological analyzer. If you can suggest such a solution we would surely consider it as a future improvement for the Webhelp search. Kind regards, Sorin Naoki Hirai wrote: > Hi, > > > > I like Oxygen WebHelp very much and recommend it to Japanese users. The > WebHelp is sophisticated online manual solution, but one issue has still > remained for Japanese users. That is a Japanese search. For Japanese > it's difficult to extract words from sentences. Because the words are > not separated by spaces. Therefore, in general, a morphological analyzer > is used to extract the words from the sentences. Recently, an open > source Japanese morphological analyzer which is called "Kuromoji" has > become popular. The Apache Solr has introduced Kuromoji as the > morphological analyzer. > > > > So, my feature request is that Oxygen WebHelp plug-in will incorporate > Kuromoji as the morphological analyzer. And add a parameter which > selects a stemmer for generating a WebHelp output. I can help the > development and the evaluation. > > > > Please have a thought. > > > > Best regards, > > Naoki _______________________________________________ oXygen-user mailing list oXygen-user(a)oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user

2 1

[Ann] focheck - Validate XSL-FO and Antenna House extensions in oXygen or standalone
by Tony Graham 14 Apr '15

14 Apr '15

Antenna House is pleased to announce the availability of 'focheck' as an add-on oXygen framework for validating XSL-FO and Antenna House extensions. 'focheck' bundles a Relax NG schema and a Schematron grammar in an oXygen framework for detailed validation of XSL-FO within oXygen XML Editor. You can, of course, also use the 'focheck' Relax NG and Schematron outside of oXygen, either together or separately. The Relax NG handles structural validation and the Schematron handles the additional constraints that cannot be expressed in Relax NG. The Schematron parses property value expressions using an XSLT-based parser generated by the REx parser generator plus an XSLT library for reducing the parse tree to XSL-FO datatypes. 'focheck' is available on GitHub at https://github.com/AntennaHouse/focheck. If you want to go straight to installing it as an add-on, the Update Site URL to use is https://github.com/AntennaHouse/focheck/raw/master/add-on.xml 'focheck' is a work in progress. It does not (yet) handle every XSL-FO property or every requirement in the XSL-FO spec, nor does it evaluate either functions or relative lengths. Pull requests and new issues are welcome. I will also be talking about 'focheck' at XML London 2015 in June. [1] And, of course, thanks go to the folks at Oxygen XML Editor Support for helping with some of the issues encountered. 'focheck' is open source licensed under the Apache License, Version 2.0. Regards, Tony Graham. -- Senior Architect XML Division Antenna House, Inc. ---- Skerries, Ireland tgraham(a)antenna.co.jp [1] http://xmllondon.com/programme#Tony-Graham

2 2

"FO PDF" scenario
by scott ashmead 14 Apr '15

14 Apr '15

Hi, I'd like to generate a PDF from an .fo file. When I open the .fo file in Oxygen, I thought I would see a "FO PDF" transform scenario, but I don't see it. Is there a properties setting that controls this? Thank you,Scott

3 2

MarkLogic 8 denuding issues with Oxygen v16 and earlier
by Ross A 14 Apr '15

14 Apr '15

Hi Where can I obtain Oxygen XML Editor v17 beta? I'm using MarkLogic 8 with Oxygen v14 Enterprise and having debugging errors. I heard the Oxygen v17 address those issues with MarkLogic 8, but there is also v17 beta out there that I can use? Thx Sent from my iPhone

2 1

Oxygen does not recognize DITA <steps-informal>
by Mark Giffin 14 Apr '15

14 Apr '15

I get an error with this markup, which I think should be valid for DITA 1.2: <task id="d3e123"> <title>Words here</title> <taskbody> <steps-informal></steps-informal> </taskbody> </task> Here's the error: ------- E [Xerces] Unexpected element "steps-informal". The content of the parent element type must match "(prereq?,context?,(steps|steps-unordered)?,result?,example?,postreq?)". ------- Shouldn't Oxygen call this valid? Here's the spec for it: http://docs.oasis-open.org/dita/v1.2/os/spec/langref/steps-informal.html Thanks, Mark

2 1

[Ann] New maintenance build available for oXygen 16.1 (2015040615)
by Oxygen XML Editor Support (Adrian Buza) 08 Apr '15

08 Apr '15

Dear oXygen users, We announce the release of a new maintenance build (2015040615) for oXygen 16.1 (XML Editor, XML Developer, XML Author). The build number can be verified in the Help -> About dialog box from the application (next to the version number). You can download the new installation kits from our web site: http://www.oxygenxml.com/download.html Here you can find the complete list of bug-fixes: http://www.oxygenxml.com/build_history.html#2015040615 You can follow our oXygen release/build RSS feed here: http://www.oxygenxml.com/rssBuildID.xml Please let us know if you encounter any problems with this new build. Regards, Adrian -- Adrian Buza oXygen XML Editor and Author Support Tel: +1-650-352-1250 ext.2020 Fax: +40-251-461482 support(a)oxygenxml.com http://www.oxygenxml.com

1 0

[Ann] Oxygen XML Editor 17.0 beta
by Oxygen XML Editor Support (Adrian Buza) 07 Apr '15

07 Apr '15

Dear oXygen users, We are happy to announce that version 17.0 of oXygen XML Editor is close to being released. We have decided to offer a beta version prior to the final release to give you the opportunity to send us your feedback on the new features. Below, please see information about: * Downloading - oXygen 17.0 beta downloading links and notes * Licensing - a trial license key for testing * What's new - a summary of the most important new features in version 17.0 = Downloading = Windows 64-bit: http://www.oxygenxml.com/beta17/Windows64/oxygen-64bit.exe Windows 32-bit: http://www.oxygenxml.com/beta17/Windows/oxygen.exe OS X/Java SE 6: http://www.oxygenxml.com/beta17/MacOSX/oxygen.zip Linux/All Platforms: http://www.oxygenxml.com/beta17/All/oxygen.tar.gz Eclipse/ZIP: http://www.oxygenxml.com/beta17/Eclipse/com.oxygenxml.editor_17.0.0.v201503… Important Notes: - This build is meant for testing purposes only. Do not use it for production work. - You should install this beta version in a different directory than your current Oxygen installation. For Windows, we also recommend that you disable file associations during the installation to preserve your current Oxygen file associations with the various XML file types. - The OS X .zip distribution requires Java SE 6 from Apple, which is available here: http://support.apple.com/kb/DL1572 - For Linux, you need to have installed either OpenJDK 7 (http://openjdk.java.net/install/) or Java SE 8 JRE/JDK from Oracle (http://www.oracle.com/technetwork/java/javase/downloads/index.html) - The "All Platforms" (.tar.gz) distribution includes launchers for Mac (Oxygen XML Editor.app or oxygenMac.sh), Linux (oxygen.sh), and Windows (oxygen.bat). - All feedback is welcome. = Licensing = If you already have a license key for Oxygen XML Editor with an active SMP, it will also work for this beta version. If you don't have one, a registration dialog box will open and you can use the following 30-day trial license key: ------START-LICENSE-KEY------ Registration_Name=oXygen XML v17 Beta Company= Category=Enterprise Component=XML-Editor, XSLT-Debugger, Saxon-SA Version=17 Number_of_Licenses=1 Date=03-30-2015 Trial=31 SGN=MCwCFADtFJ2DUmrsYwVq4sDUfqegwtpdAhRZLID8yK5+0R+UxlPRnLQ9fxCMFQ\=\= -------END-LICENSE-KEY------- = What's new in Oxygen XML Editor 17.0 = XML Quick Fixes: * Quick Fixes for Relax NG Errors * Schematron Quick Fixes XML Refactoring: * XML Refactoring Tool Visual XML Editing: * LESS Support in the Author Mode * Change the Tag Display Font * Actions to Insert Multiple Rows or Columns * The fileFilter Property is Available for URLChooser Form Control * Bold, Italic, and Underline Actions Support Multiple Selections Interface: * Customizable Toolbars * Color Themes * Improved HiDPI and Retina Support * Online Help Option DITA Support: * Search for Orphaned Resources Not Referenced in DITA Maps * Insert Image Reference Wizard * Validation Warning for References to Missing Topics and Images * Publish DITA Maps to Web Presentations * Auto-Detect Transformation Types and Parameters for Newly Installed DITA OT Plugins * CSS Improvements * DITA Map CSS Can Render Subject Scheme Map Elements * Support for DITA OT 2.0 * Check for Duplicate Topic IDs in a DITA Map WebHelp: * WebHelp Output Embeddable in iframe Element * WebHelp Context-Sensitive Help System * WebHelp System Supports LDAP Authentication * WebHelp System Supports Right-to-Left (RTL) Oriented Languages * Search Engine Optimization for WebHelp Output CSS: * CSS Inspector View * Support for Selecting/Combining Multiple CSS Styles in Author Mode * Support for editing LESS Stylesheets * Code Templates Included in the Content Completion List for Form Control Functions * New HTML Content Form Control * Define Actions for Button and Button Group Form Controls Directly in the CSS * Additional Properties Supported for the oxygen Media Type * The min-width and max-width Properties Supported for the CSS @media Rule * The font-family Property is Fully Supported * Support for position Property * Support for min-height Property * Support for letter-spacing Property * oxy_url Function with Editor Variables SVN Client: * Improvements to the Create Patch and Export Actions * Action to Display Additional Information About Versioned Items * Additional Improvements and Bug Fixes API: * Intercept List of Actions Provided by a Callout * Tree Component for Consistent Look and Feel * Customize Author Menu [Eclipse] * Customize Text/Author Contextual Menus [Eclipse] * Customize the Toolbars in the DITA Maps Manager [Eclipse] * Add Custom Browse Actions to Input Dialogs [Eclipse] * API for Customizing the Author Toolbar [Eclipse] * API for Providing Editor Adapters [Eclipse] * Plugin Extension to Specify Location of Custom Refactoring Operations * Styles Filter Extension Point [Eclipse] * ExtensionsBundle Extension Point [Eclipse] * Provide Text for a DITA Link [Eclipse] * Expand/Collapse Foldable Elements in Author Mode * Customize Drop-Down Buttons on a Toolbar [Eclipse] * Easier Way to Provide Documentation for Elements * Filter Errors Presented to the End User * Choose the Custom CSS to be Included in the Styles Drop-down List * Support for Composite Toolbars * API to Find Tracked Attribute Changes * Obtain a Reader Object of a URL Other: * Support for Configuring Proposals in the Content Completion Assistant * Ready for MarkLogic 8 * Automatic Escaping of Characters that Exceed the XML Encoding * Option to Lock Local Resources * Support for the JATS Document Type * Support for XLIFF 1.2 and 2.0 Documents * Compare Files Tool Includes Support for XML Fragment Comparison * Deprecated Support for Documentum CMS * Define Shortcut Keys for Code Templates Component Updates: * Apache HTTP Client 4.3.5 * Calabash 1.0.25 * eXist DB 2.2 * JSch 0.1.51 * Eclipse 4.5 Please let us know if you encounter any problems with this build. Again, all feedback is welcome. Best regards, Adrian -- Adrian Buza oXygen XML Editor and Author Support Tel: +1-650-352-1250 ext.2020 Fax: +40-251-461482 support(a)oxygenxml.com http://www.oxygenxml.com

2 3

Re: [oXygen-user] XPath keywords
by Nico Kutscherauer 02 Apr '15

02 Apr '15

Dear oXygen team, This popped up today and I thought it would be cool if you could implement it (maybe in v17.1, if it is to much for v17): It would be nice if the XPath auto completion would know the following keywords and operators: - except - intersect - union - some - every - in* - satisfies* - if - then* - else* - for - return* - or - and - instance of - castable as ...did I missed one? *depending on the required keywords before Best Regards and thanks for v17 beta! Nico

2 1

cvc-elt.1.a: Cannot find the declaration of element 'val'
by Simon 01 Apr '15

01 Apr '15

Here is my problem with using DITA-OT. I am just starting to use the "Filtering" feature when I encounter the following issue: Here is how I run the DITA-OT: java -jar lib/dost.jar /i:/conditional-text.ditamap /filter:plumbers.ditaval /outdir:. /transtype:pdf2 And here is the result: BUILD FAILED D:\DITA-OT\build.xml:44: The following error occurred while executing this line: D:\DITA-OT\plugins\org.dita.base\build_preprocess.xml:24: Failed to run pipeline: [DOTJ012F][FATAL] Failed to parse the input file 'D:\DITA-OT\conditional-text.ditamap'. The XML parser reported the following error: : conditional- text.ditamap Line 2:cvc-elt.1.a: Cannot find the declaration of element 'val'. Here is the content of my conditional-text.ditamap <?xml version="1.0" encoding="UTF-8"?> <val> <prop att="audience" val="electricians" action="include"/> <prop att="audience" val="plumbers" action="exclude"/> </val> Can anyone tell me how to fix this?Thanks!

2 1

Toolbar action for specific transformation scenario?
by Tony Graham 25 Mar '15

25 Mar '15

Is it possible to configure a toolbar action that will run a specific transformation scenario from the current framework? It's possible to make one scenario the default scenario, I know, but I'm looking at providing multiple transformation scenarios, and I'd prefer it if the eventual users could choose their actions without even having to go to the trouble of selecting and unselecting items in the 'Transformation Scenarios' view, if that's possible. Regards, Tony Graham. -- Senior Architect XML Division Antenna House, Inc. ---- Skerries, Ireland tgraham(a)antenna.co.jp

2 3