September 2022 - oXygen-user - www.oxygenxml.com

[ANN] Version 5.0.0 of the Oxygen Batch Documents Converter add-on has been released!
by Alin Belu 30 Sep '22

30 Sep '22

Hello everyone, We are excited to announce that *version 5.0.0* of the *Oxygen Batch Documents Converter add-on* is now available! For the newest version of the add-on, our team of developers worked hard to bring you an impressive list of useful improvements: *** OpenAPI to DITA *** * You can now convert JSON or YAML files that use and conform to the OpenAPI specification (versions 2.0, 3.0, or 3.1) to DITA documents and there is a 'Create DITA maps from OpenAPI documents' option that can be selected to instruct the converter to split the documents into separate topics that are referenced in a DITA map. *** Word to HTML/DITA *** * Improved the Word styles mapping configuration by inheriting the style configuration of the custom style from the base style. * SVG images embedded in Word documents are preserved as SVG. * IDs that result from image and table bookmarks are now handled better to find the correct location. * Improved the IDs generation on topics and sections by using the text from headings. * Improved the handling of tables by preserving header row information during the conversion. * Fixed a case where a list that contains content between list items was broken into multiple lists. * Fixed a case where multiple ordered lists were merged into one. * Fixed a case where the conversion failed when the document contained duplicate mappings between numberings and styles. * Fixed a case where WMF images were not handled by the converter. * Fixed a case where the DITA result contained an invalid MathML equation. * Fixed a case where the DITA result contained images wrapped in the 'b' element. * Fixed a case where the value edited in the Word Styles Mapping table from the preferences page was not saved. * Updated the Java-Mammoth library used for Word to HTML/DITA conversions to version 1.5.0. *** HTML to DITA *** * Improved the conversion of object elements from HTML by adding a proper 'outputclass' attribute in the DITA result. * Added an option in the conversion dialog box that allows you to decide whether or not the 'div' elements will be ignored. * Fixed a case where 'id' and 'class' attributes were lost when breaking paragraphs by processing the 'br' elements. *** Markdown to DITA *** * Added support for the Markdown abbreviations. * Improved the conversion to allow processing of headings specified as HTML in the Markdown documents. * Improved the handling of the local references. * Improved the handling of the HTML anchor elements in the Markdown documents. *** Other *** * The formatting of 'pre' elements is prevented when converting HTML to XHTML. * Fixed the layout of the preferences page because it was not entirely visible on low resolution screens. To manually install the add-on, please follow these instructions: 1. Go to Help > Install new add-ons to open an add-on selection dialog box. 2. Enter or paste https://www.oxygenxml.com/InstData/Addons/default/updateSite.xml in the Show add-ons from field. 3. Select the Batch Documents Converter add-on and click Next. 4. Read the end-user license agreement. Then select the I accept all terms of the end-user license agreement option and click Finish. 5. Restart the application. Result: A Batch Documents Converter submenu will now be available in the Tools menu and in the contextual menu. This submenu will contain a list of the various types of available conversions. Selecting one of the types of conversions will open a dialog box where you can configure options for the conversion. For more information on the Oxygen Batch Documents Converter add-on, you can check the page below: https://www.oxygenxml.com/doc/ug-editor/topics/batch-converter-addon.html We hope you will find this new release useful and as always, your feedback is welcome! Best regards, Alin -- Alin Belu Oxygen XML Editor

1 0

[Ann] New maintenance build available for oXygen 24.1 (2022092207)
by Oxygen XML Editor Support (Adrian Buza) 23 Sep '22

23 Sep '22

Dear oXygen users, We announce the release of a new maintenance build (2022092207) for oXygen 24.1 (XML Editor, XML Developer, XML Author, XML WebHelp, PDF Chemistry, Publishing Engine). 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#2022092207 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

1 0

Relax NG validation messages
by David Birnbaum 19 Sep '22

19 Sep '22

Dear oxygen-user(a)oxygenxml.com, I have a question about the error messages <oXygen/> reports when validating a Relax NG rule that types an item as xsd:integer. My test XML is: <?xml version="1.0" encoding="UTF-8"?> <?xml-model href="n.rnc" type="application/relax-ng-compact-syntax"?> <stuff>1</stuff> and my test Relax NG is: start = stuff stuff = element stuff { xsd:integer {minInclusive = "1" maxInclusive = "1"} } As I expected, both "1" and "01" pass validation. Initially I (erroneously) expected "1.0" to pass because I thought validation cared only about the value space, and not the lexical space, and it didn't because I had misunderstood how integer was defined. Section 3.3.13 integer of https://www.w3.org/TR/xmlschema-2/ plainly says "disallowing the trailing decimal point", a limitation of the lexical space that automatically disallows the trailing zero. I am, though, puzzled by the error message that <oXygen/> displays for "1.0", which reads: character content of element "stuff" invalid; must be a decimal number without any significant digits after the decimal point I think that the wording of the error message suggests that "1." should pass, since the message seems to implies that the decimal point is fine, and the mistake was putting a zero after it. Yet validating "1." raises: character content of element "stuff" invalid; must be an integer This is consistent with the spec, as cited above, but also, I think, misleading because the *value* of "1.0" is an integer, and the prohibited trailing decimal point is about the lexical representation of the value. The error message doesn't distinguish value space from lexical space, although it could. Am I alone in thinking that these two error messages could be clearer because the error in both cases is the same: the lexical space of xsd:integer does not permit a decimal point? Neither of these messages fingers the decimal point as the invalid part of the content. Sincerely, David

2 1