- oXygen-user - www.oxygenxml.com

About oXygen XML Editor
by About oXygen XML Editor 22 May '15

22 May '15

About oXygen XML Editor /////////////////////////////////////////// Schematron Checks to help Technical Writing Posted: 21 May 2015 03:56 AM PDT http://feedproxy.google.com/~r/AboutOxygenXmlEditor/~3/eQSoXbR5Vjg/schematr… The Oxygen XML Editor User's Manual is written in DITA. In an older post I described in more detail how we collaborate internally on our User's Guide Project. And we also made available a copy of our User's Manual as a project on GitHub. During these years on working on it, we progressively developed a set of simple rules which were originally kept in a plain text document. The problem is that nobody can really remember all these rules when actually writing. So recently we started to migrate these rules to Schematron and have them reported automatically has validation warnings and errors while editing the topics. And with the release of Oxygen 17 we can now also add quick fixes for each of these problems. So below I will try to tell you what each rule imposes and what it's Schematron implementation looks like. If you want to quickly test these rules on your side, you can add them to the Schematron file which is used by default to validate DITA topics located in: OXYGEN_INSTALL_DIR/frameworks/dita/resources/dita-1.2-for-xslt2-mandatory.sch. Try as much as possible to add at least an indexterm element in each topic. This is useful when the Index page is created for the PDF output or the Index tab is created for the WebHelp output. As this is not a requirement, we wanted to report this issue as an error. The end result looks like this: And the Schematron pattern looks like this:<pattern xmlns:sqf="http://www.schematron-quickfix.com/validator/process"> <rule context="/*"> <assert test="prolog/metadata/keywords/indexterm" role="warn" sqf:fix="addFragment"> It is recommended to add an 'indexterm' in the current '<name/>' element. </assert>  <sqf:fix id="addFragment"> <sqf:description> <sqf:title>Add the 'indexterm' element</sqf:title> </sqf:description> <sqf:add match="(title | titlealts | abstract | shortdesc)[last()]" position="after" use-when="not(prolog)"> <prolog xmlns=""><metadata><keywords><indexterm> </indexterm></keywords> </metadata></prolog> </sqf:add> </sqf:fix> </rule> </pattern> The ID of each topic must be equal to the file name (minus the extension). One of the outputs we produce (I think CHM) had a limitation when building the context mapping between help IDs and actual HTML content so this was an important rule for us, thus an error is reported on this. Also a quick fix is added to auto-correct the topic ID based on the file name. The end result looks like this: and the Schematron pattern is: <sch:pattern> <sch:rule context="/*[1][contains(@class, ' topic/topic ')]"> <sch:let name="reqId" value="replace(tokenize(document-uri(/), '/')[last()], '\.dita', '')"/> <sch:assert test="@id = $reqId" sqf:fix="setId"> Topic ID must be equal to file name. </sch:assert> <sqf:fix id="setId"> <sqf:description> <sqf:title>Set "<sch:value-of select="$reqId"/>" as a topic ID</sqf:title> <sqf:p>The topic ID must be equal to the file name.</sqf:p> </sqf:description> <sqf:replace match="@id" node-type="attribute" target="id" select="$reqId"/> </sqf:fix> </sch:rule> </sch:pattern> Report when plain links or related links to web resources have the same text inside them as the value of the @href attribute. We had cases in which writers would input web links like this:<xref href="http://www.google.com" format="html" scope="external">http://www.google.com</xref>which is redundant because when you set no text to the link, the publishing uses the @href attribute value as the link text. So we wanted to report such cases as warnings and to have a quick fix which removes the link text: The Schematron pattern looks like this:<sch:pattern> <sch:rule context="*[contains(@class, ' topic/xref ') or contains(@class, ' topic/link ')]"> <sch:report test="@scope='external' and @href=text()" sqf:fix="removeText"> Link text is same as @href attribute value. Please remove. </sch:report> <sqf:fix id="removeText"> <sqf:description> <sqf:title>Remove redundant link text, text is same as @href value.</sqf:title> </sqf:description> <sqf:delete match="text()"/> </sqf:fix> </sch:rule> </sch:pattern> Avoid using the @scale attribute on images. We wanted to smooth scale images in an external image editor so it was prohibited to use the @scale attribute on images. The Schematron pattern for this:<pattern> <rule context="*[contains(@class, ' topic/image ')]"> <assert test="not(@scale)"> Dynamically scaled images are not properly displayed, you should scale the image with an image tool and keep it within the recommended with and height limits. </assert> </rule> </pattern> We have an upcoming webinar dedicated to Schematron Quick Fixes. There is a W3C working group for XML Quick Fixes and you calso read the SQF Quick Fix specification if you want to become more familiar with the technology. We also have a GitHub project which tries to combine the notion of a style guide for writing documentation inside a company with a very simple manner of defining checks which can be applied to impose the styleguide rules. I would be interested in your feedback, especially if you have checks that you perform right now on your content and you consider that they might benefit others. -- You are subscribed to email updates from "About oXygen XML Editor." To stop receiving these emails, you may unsubscribe now: https://feedburner.google.com/fb/a/mailunsubscribe?k=y_tRXtumvTurKTedh51Jnl… Email delivery powered by Google. Google Inc., 1600 Amphitheatre Parkway, Mountain View, CA 94043, United States

1 0

Default zoom factor in oXygen XML Editor 17
by Yves Barbion 21 May '15

21 May '15

Hi group Is there a way to reset or revert to the default zoom factor in oXygen XML Editor 17? In one of the DITA topics I was editing, I zoomed in to, say 150 % (or something). I did so by holding down the CTRL key and using the scroll wheel on my mouse. Every topic I open or create from now on seems to be displayed at this zoom factor. I have tried to reset my "layout" (workspace) and to quit and restart oXygen, but that does not seem to help. I also looked up "zoom" in the oXygen preferences and in the Help file, but I didn't find anything relevant there. Thanks. -- Yves Barbion www.scripto.nu

2 2

Opening dialog boxes from xslt - It works!
by Patrik.Stellmann＠gdv-dl.de 20 May '15

20 May '15

Hi, I lately implemented custom saxon instructions that allow to create a message boxes or option dialogs from within an XSLT script. Since it turned out to be pretty easy to implement and very useful within my framework, I just wanted to share this idea - and the joy over oxygen, that even this is possible. One use-cases would be a transformation that potentially overwrites an existing file and asks the user before doing so (if the file already exists). The code looks like this: <xsl:if test="java:fileExists($myFile)"> <xsl:variable name="userDecision" as="xs:integer"> <gui:option-dialog title="Warning" options= "('Continue', 'Abort')" default="1"> <xsl:text/>The file '<xsl:value-of select= "$myFile"/>' already exists and will be overwritten.<xsl:text/> </gui:option-dialog> </xsl:variable> <xsl:if test="$userDecision = 1"> <xsl:message terminate="yes">Abort on user request </xsl:message> </xsl:if> </xsl:if> To implement such extension instructions you will have to implement your own java library and put it into oxygens lib folder. To do so follow the saxon documentation at http://www.saxonica.com/documentation/#!extensibility/instructions and - much more important - look at the sample of Saxon-SQL, which is included in the open source edition of saxon: http://sourceforge.net/projects/saxon/files/Saxon-HE/) Make sure to use the same version as included into oxygen! To open the actual dialog you can use something like JOptionPane.showOptionDialog( (Frame)PluginWorkspaceProvider.getPluginWorkspace ().getParentFrame(), textString, titleString, (optionList.size() == 2) ? JOptionPane.YES_NO_OPTION : JOptionPane.YES_NO_CANCEL_OPTION, JOptionPane.PLAIN_MESSAGE, null, optionList.toArray(new String[optionList.size()]), defaultOption); (If someone should be interested - I will also gladly share my java code.) There is also an entry in the forum for this: http://www.oxygenxml.com/forum/topic11531.html Regards, Patrik GDV Dienstleistungs-GmbH & Co. KG Glockengießerwall 1 D-20095 Hamburg www.gdv-dl.de Sitz und Registergericht: Hamburg HRA 93 894 USt.-IdNr : DE 205183123 Komplementärin: GDV Beteiligungsgesellschaft mbH Sitz und Registergericht: Hamburg HRB 71 153 Geschäftsführer: Dr. Jens Bartenwerfer Michael Bathke Heiko Beermann Volker Sonnenburg ------------------------------------------------------------------ Diese E-Mail und alle Anhänge enthalten vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe der E-Mail ist nicht gestattet. This e-mail and any attached files may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distributionof the material in this e-mail is strictly forbidden.

1 0

Oxygen 17 UI improvements webinar on Wednesday
by Oxygen XML Editor Support (Radu Coravu) 19 May '15

19 May '15

Hi everybody, Just wanted to remind you that on Wednesday (May 20, 2015) we'll be hosting a free webinar with the new UI improvements we added in Oxygen 17: > http://www.oxygenxml.com/events/2015/webinar_oxygen_17_ui_improvements.html So if anybody's interested, please join in. Regards, Radu Radu Coravu <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com

1 0

New CSS visual rendering improvements in Oxygen 17.0
by Radu Coravu 15 May '15

15 May '15

Hi everybody, I wrote a small article about the new CSS improvements in Oxygen 17.0. You can find it here: > http://blog.oxygenxml.com/2015/05/visual-rendering-css-improvements-in.html Feedback is as always welcomed. Regards, Radu Radu Coravu <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com

1 0

[Ann] New maintenance build available for oXygen 17.0 (2015051321)
by Oxygen XML Editor Support (Adrian Buza) 15 May '15

15 May '15

Dear oXygen users, We announce the release of a new maintenance build (2015051321) for oXygen 17.0 (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#2015051321 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

Go to or search a particular line from command prompt
by Andreas Wagner 12 May '15

12 May '15

Hi list, we are currently exploring ways to establish a semi-automatic workflow for post-digitization tasks with TEI files. An external tool will generate lists of unknown words along with a value that uniquely identifies the line that the respective word is in, so I would like to be able to make oxygen go to the relevant line easily while still working in that list. (I am currently thinking along the lines of hyperlinks, or office macros in the list/spreadsheet.) Can I pass an action like "open file xy and go to line number yz" or "open file xy and search for string 'yz'" to oxygen as a commandline option (like 'vim +yz xy' or 'vim +/yz xy')? Of course I am also open to alternative approaches, although I suppose coding an oXygen plugin in java for that purpose surpasses my abilities. Thanks for any pointers, Andreas -- Dr. Andreas Wagner Project "The School of Salamanca" Academy of Sciences and Literature, Mainz and Institute of Philosophy Goethe University Frankfurt http://salamanca.adwmainz.de IGF HP 25 / R 2.455 Norbert-Wollheim-Platz 1 60629 Frankfurt am Main Tel. +49 (0)69/798-32774 Fax +49 (0)69/798-32794

2 1

oXygen XML Editor 17 support for DITA-OT 2.1?
by Jim Henderson 11 May '15

11 May '15

Hi, Really loving oXygen 17 here after just a week of use - the changes to the webhelp transformation (particularly the ability to embed the output in an iframe) is something that arrived at a perfect time for me, as I was in the middle of trying to figure out how to add our corporate header/footer to the output, and this made it much simpler. Something that we're getting ready to start doing is incorporating content written by non-writers - support staff and software developers. With the changes in DITA-OT coming up and the support for Commonmark, we've decided to leverage those capabilities to simplify our processes. I know oXygen 17 has support for DITA-OT 2.0, but I'm wondering if that support extends to 2.1, which is required to use the dita-ot-markdown plugin. As a secondary question, does anyone know of a transformation to get from DITA to Commonmark? Thanks, Jim -- [image: Ping Identity logo] <https://www.pingidentity.com/> Jim Henderson Technical Writer @ jhenderson(a)pingidentity.com [image: phone] +1 720.390.3443 Connect with us… [image: twitter logo] <https://twitter.com/pingidentity> [image: youtube logo] <https://www.youtube.com/user/PingIdentityTV> [image: LinkedIn logo] <https://www.linkedin.com/company/21870> [image: Facebook logo] <https://www.facebook.com/pingidentitypage> [image: Google+ logo] <https://plus.google.com/u/0/114266977739397708540> [image: slideshare logo] <http://www.slideshare.net/PingIdentity> [image: flipboard logo] <http://flip.it/vjBF7> [image: rss feed icon] <https://www.pingidentity.com/blogs/> <http://www.cloudidentitysummit.com/> <http://www.cloudidentitysummit.com/>[image: http://www.cloudidentitysummit.com/] <http://www.cloudidentitysummit.com/>

2 1

[Ann] Training Course - DITA Authoring with <oXygen/> XML Author – 19-21 May 2015*
by Sarah Draper 11 May '15

11 May '15

This training course, designed by Dr Tony Self and delivered by our Partner, Mekon, will give both experienced and novice DITA technical authors the knowledge they need to make the most of <oXygen/>XML Author. Upon successful completion of this course, attendees will be able to work with projects, create and edit DITA and other XML documents using <oXygen/> and transform source files to Web, ePUB and PDF deliverable documents. Using a comprehensive training project and practical exercises attendees will learn about:- * Topic workspace – opening and closing, previewing, editing topic elements and attributes, cross-references * Editing modes * Map manager – creating and editing maps, cross-references * Projects and folder structures * Working with tables, images and lists * Spell-check, search * Conditions/profiling * Re-usable content * Using Help * Authoring shortcuts * Transformation scenarios and their application * Reviewing features * Validation, troubleshooting and shortcuts For further information or to book a place please contact Sam Cammock at Mekon: sam.cammock(a)mekon.com <mailto:sam.cammock@mekon.com> or call +44 (0)208 722 8400 Best regards, Sarah Draper Director of Channel Sales & Marketing M: +44 (0) 7890 371908 Email:sarah_draper@oxygenxml.com http://www.oxygenxml.com

1 0

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

08 May '15

Thanks for the quick turnaround. As a related but side note, I'm thinking to add to WebHelp a simple fuzzy query matching/scoring based on the Levenshtein distance ratio between the query and the index. Have you considered it in the past? I thought you might have considered it, as it would benefit not only Far Eastern cultures but probably also Western cultures. (albeit some Western's have the stemmer in WebHelp) 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 10:50 PM To: T. Hatanaka; oXygen-user(a)oxygenxml.com Subject: Re: [oXygen-user] Feature request: Improvement of Japanese search for WebHelp Hi, Right, good catch! I just fixed it, the search box will allow in Oxygen 17.0 also search words of length shorter than three characters if the language of the content is Japanese. Best regards, Sorin <oXygen/> XML Editor http://www.oxygenxml.com On 4/30/2015 4:13 PM, T. Hatanaka wrote: > 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

selecting multiple attribute values
by Yves Barbion 08 May '15

08 May '15

Hi group I have just installed oXygen XML Editor 17 and I love it! Great work again from the guys from Syncro Soft. Thanks! So here is my first question: I've got a ditamap with a subjectscheme map, so my attribute values are displayed in a drop-down list in the Attributes pane. Is there a way to select multiple attribute values in this drop-down list? [image: Inline image 1] Thanks -- Yves Barbion www.scripto.nu

2 1

[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