- oXygen-user - www.oxygenxml.com

This might have been foolish, but ...
by Ben McGinnes 26 Sep '15

26 Sep '15

Hello, So I was poking around in the oxygen/templates/ directory and had a little look at the ePub 3.0 template in there. Given what I've said about ePub 3.0 and internal structure in the past, it was inevitable that I modify the template in there to add a version with subdirectories for assorted purposes and it certainly looks like it's behaving at least as far as being an additional global template. Obviously there would be no point in mentioning it here if I wasn't sharing. Anyone interested can find it here: https://github.com/adversary-org/epub-tools/tree/master/oxygen/templates In that directory you'll find the original template, mainly for comparison (and yes, making an oxygen/templates/ path in that repo is solely to make it obvious to others where to install/copy to). The template I'm referring to here is the one called "EPUB 3.0 DroidBook.epub.bin" and is so named for the embedded font I've dumped in there (Droid Sans Fallback Full). There's another template in there as well, "EPUB 3.0 BrythonBook.epub.bin" and you're welcome to play with it, of course, but I should warn you that it is *highly* experimental. It's basically built on the DroidBook template, but includes a complete implementation of Brython. Brython is an implementation of Python 3.3 for browsers and javascript. It allows you to use python code in the same way as one might normally use javascript and since ePub 3 is supposed to allow a subset of javascript I figured I'd see whether I could get this thing to work in an ePub too. I won't be too surprised if it goes nowhere and it's quite possible it might do Bad Things™ instead. On the other hand, there's nothing lost by trying it and seeing what breaks. Even if it doesn't play nicely with ePub, it ought to play quite well with regular HTML and XHTML projects. As is amply demonstrated on its website and described on GitHub: http://brython.info/ https://github.com/brython-dev/brython If anyone does decide to play with Brython and ePub, I'll be interested to hear how it goes; whether that be a success or a catastrophic failure. With regards to licenses; the original templates from oXygenXML followed fairly basic specifications from the IDPF, Brython uses a BSD license (the license file is in the ePub, in the resurced subdirectory with the README and the Droid Sans font). My bits barely qualify as needing a license, but if you must have one then my WTFNMF Public License ought to do the job nicely. You can find the terms of that here: https://github.com/adversary-org/wtfnmf Oh, yes, the manifest for the Brython experiment does include all the files for the implementation (you're welcome). So it should just be a matter of calling brython.js by its relative path in any HTML or XHTML file to make it work. At least in theory, there's been zero testing yet. Regards, Ben -- Ben McGinnes http://www.adversary.org/ Twitter: benmcginnes Writer, Systems Administrator, Trainer, ICT Consultant GPGME Python 3 API Maintainer, GNU Privacy Guard https://www.gnupg.org/ Encrypted email preferred, primary OpenPGP/GPG key: 0x321E4E2373590E5D OpenPGP/GPG key here: http://goo.gl/GVGwT and http://goo.gl/SDs0D OpenPGP/GPG key transition: http://www.adversary.org/keyswitch.txt.asc

1 0

Autumn conferences
by George Bina 22 Sep '15

22 Sep '15

Hi all, After some quiet time during the summer, we will have a busy schedule this autumn. First, we will be in San Jose, California, next week on Oct 1-2 at the Information Development World conference. You can meet us at the oXygen XML Editor stand in the exhibition area or attend or session on Friday, 2:00pm-2:45pm: Single-Source Publishing Across Multiple Formats https://www.eiseverywhere.com/ehome/113382/schedule/ After that, we will participate also this year at the TEI Members Meeting in Lyon, France. We will host a half day workshop on Oct 28 http://tei2015.huma-num.fr/en/workshops/#item3 If you attend TEI Members Meeting and you are interested in extending the TEI support in oXygen or to find the latest additions to oXygen please register to join us there: https://docs.google.com/forms/d/1Bd9fGF7CY9V5gh9o7ukKhLX-iVMezu3LV2wVOVucXu… November will be the busiest month, we start with the TCWorld conference by Tekom, taking place in Stuttgart, where we have 3 presentations in the main conference program, plus one product presentation, plus a larger stand where you are welcome to meet us http://conferences.tekom.de/tcworld15/conference-program/conference-program/ A few days after Tekom we move to Munich and we turn into hosts, as we organize the second edition of the DITA-OT Day event, a conference dedicated to the core engine behind DITA implementations, the DITA-OT open source project: http://www.oxygenxml.com/events/2015/dita-ot_day.html This is a free event but registration is required. We organize the DITA-OT Day in the pre-conference day of DITA Europe, and at the same location, so it should be really easy to attend both events - or event all 3 events in one trip: TCWorld, DITA-OT Day and DITA Europe. We plan to end the 2015 events with DITA Europe where we will have a stand where you can meet our team as well as two interesting presentations at the conference https://ditaeurope.infomanagementcenter.com/ Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com

1 0

In-element whitespace and Author Mode
by Andreas Wagner 18 Sep '15

18 Sep '15

Dear list, I am sorry for bringing up yet another whitespace question. I almost believe that in XML the devil lives in the whitespaces. Also, it is quite possible that our problem is specific to our particular situation and of no interest to other projects. But then again, maybe someone is able to help nonetheless. We deal with TEI xml documents recording linebreaks that in many cases are not meant to represent a word boundary: <lb n="016_011"/>que con el pre<lb break="no" rendition="#noHyphen" n="016_012"/>sidente o juez que reside en la prouincia: puede <lb n="016_013"/>hazer thesoreros y receptores en su prouincia: In order to improve readability of the XML source, all our lines begin at the leftmost position of the line no matter the nesting level the current the paragraph is at. The exception is lines that begin with four spaces in order to align the @n-attribute with other lines and yet have the lb-element begin without intervening whitespace at the end of the preceding line/word fragment. But when I edit the document in author mode, it removes the linebreak within the element, so that the first of the following is a very long line and the snippet is only two lines long: <lb_n="016_011"/>que_con_el_pre<lb_break="no"_rendition="#noHyphen"_n="016_012"/>sidente_o_juez_que_reside_en_la_prouincia:_puede <lb n="016_013"/>hazer thesoreros y receptores en su prouincia: (Whitespace and indenting preferences are mentioned below.) Now our workflow relies on an external file providing links to certain places in the TEI file: <a href="W0004.xml#line=449;column=1">016_013</a> Therefore it is somewhat annoying that editing the TEI leads to ("hard") lines being drawn together and the external file increasingly pointing to wrong places. I understand that author mode parses the XML into a DOM tree and re-serializes it on save, so I don't know if this behaviour can be changed at all. But then what would you suggest how we should be approaching this problem? (Can we point to the relevant place based on the @n-attribute of the lb element? If we had to provide all the lbs with @xml:ids I think it would thwart our attempts to make the xml sources better readable. And all of this would help us with linking the two files, but the xml file would still end up with bad readability.) Thank you for any idea, Andreas P.S. I have selected the "Preserve empty lines", "Preserve text as it is" and "Preserve line breaks in attributes" in Options | Preferences | Editor/Format/XML and added "*" to the "Preserve Space" Elements. I also think I have deactivated pretty printing everywhere I could. In Editor | Edit Modes | Author | Format and indent, I have chosen "only the modified content". -- 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

copying tables from other sources
by Cwiklowski, Don 15 Sep '15

15 Sep '15

Whenever I copy a table from Word or Excel, or even HTML to a DITA reference topic all of the elements come across as <properties> (etc), but if I drop it into a Concept, Oxygen translates a table into the proper DITA elements. Does anyone know how to fix this since the majority of our Reference topics contain tables? Don Cwiklowski, Jr. Sr. Technical Communicator Customer Technical Communications | Operations and Technology MasterCard 2200 MasterCard Blvd | O'Fallon, MO 63366 tel 636-722-6802 don_cwiklowski(a)mastercard.com<mailto:don_cwiklowski@mastercard.com> [cid:image001.gif@01D0EF87.2A1DBDC0]<www.mastercard.com> Please think of the environment before printing this email. CONFIDENTIALITY NOTICE This e-mail message and any attachments are only for the use of the intended recipient and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient, any disclosure, distribution or other use of this e-mail message or attachments is prohibited. If you have received this e-mail message in error, please delete and notify the sender immediately. Thank you.

2 1

[oXygen XML Editor Blog] - A Short Story of Reuse
by oXygen XML Editor Blog 14 Sep '15

14 Sep '15

oXygen XML Editor Blog /////////////////////////////////////////// A Short Story of Reuse Posted: 07 Sep 2015 02:38 AM PDT http://feedproxy.google.com/~r/AboutOxygenXmlEditor/~3/-bqdMBmNY0Q/a-short-… Give the smartest human in the world a piece of wood and ask him/her to make paper. Give him/her no prior tools and it will take years to come up with a decent process which would result in some brown almost usable thick piece of paper. This blog post is about reuse, not necessarily reuse of tools and materials, but reuse of knowledge. Humanity has evolved not because each generation is smarter than the last one but because we learned to reuse and pass knowledge to larger and larger audiences and from one generation to another. Almost all tools that we use today are made up of quite a complex set of components which interact with each other. There is no one person in a car assembly factory who still knows all the pieces and how they come together. Although using the tool is easier than interacting with all components which make it up, you still need knowledge to operate it and in this day and age having enough people to teach how a certain tool can be used is no longer an option. You need to pass knowledge in other forms, on paper or in some kind of digital form. So I would define technical communication as a means of passing knowledge about using tools to a larger audience. Reuse in technical communication can be structured on many levels: Reuse written content by publishing it to more than one format (PDF, HTML, EPUB, MS Word). It turns out that XML is perfect for publishing content in more than one format. XML is not designed to be consumed directly by end users and its benefit lies directly in this. Your XML content should contain all the data necessary for obtaining all the output formats. So if you are using XML in your technical content, no matter what standard or custom vocabulary, you can safely check the first and most important level of reuse. Create larger publications from existing ones. Either using an XML standard like XInclude or using standards with their own diverse and powerful methods of reuse like DITA, or by performing custom techniques you can merge XML content in larger publications. Reuse content written for a certain tool to document the functionality and behavior of a very similar tool. In most mature XML standards like DITA and Docbook there is this implemented concept of profiling which allows you to dynamically filter at publishing time content marked with certain attributes from your original XML project. In this way from the same XML content you can publish documentation for multiple similar tools. Reuse smaller pieces of common content in more than one publication. Again, using XML standards like XInclude or DITA specific standards like content references you can create and maintain small libraries of reusable XML content, then reuse these components across various publications. Reuse images and other binary resources in multiple publications. Because XML content does not embed binary resources, these resources are stored separately and thus they can be reused in multiple places. So these are what I consider to be the main selling points for using XML in technical documentation. As usual any feedback is welcomed. -- You are subscribed to email updates from "oXygen XML Editor Blog." 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

3 2

About oXygen XML Editor
by oXygen XML Editor Blog 03 Sep '15

03 Sep '15

oXygen XML Editor Blog /////////////////////////////////////////// DITA 1.3 Branch Filtering - Next Generation of Reuse Posted: 02 Sep 2015 05:51 AM PDT http://feedproxy.google.com/~r/AboutOxygenXmlEditor/~3/tZnLUSz5jiU/dita-13-… Thanks to the hard working OASIS DITA TC Group the DITA 1.3 standard is quite close to being released. Oxygen 17.1 which will be released probably in September this year will have experimental DITA 1.3 support. This will include publishing using a custom build of the latest DITA Open Toolkit 2.x engine in which the main developer Jarno Elovirta has already added incipient support for key scopes and branch filtering. In this blog post I'm going to give you a small example of how branch filtering can benefit two cases of reuse which could not be done previously. You can read more about branch filtering in the DITA 1.3 specs. Case 1 - Combine Two Profiles in the Same Publication Let's say you have a DITA Project about preparing and cooking vegetables. And your DITA Map looks like this:<!DOCTYPE map PUBLIC "-//OASIS//DTD DITA Map//EN" "map.dtd"> <map> <title>Cooking vegetables</title> <topicref href="cleaningTableArea.dita" audience="novice"/> <topicref href="preparingVegetables.dita"/> <topicref href="addingExtraFlavor.dita" audience="expert"/> </map> You have some content common both for expert and novice users but you also have content which is specific for a target audience. You do not need to teach expert chefs how to clean the table and you do not want to teach novice cooks about enhanced flavoring techniques. All is fine until at some point you decide to produce a publication which contains merged inside both the novice and the expert map contents. And here's where branch filtering comes for help. You can create a main DITA Map which reuses your current DITA Map with two profiling contexts:<!DOCTYPE map PUBLIC "-//OASIS//DTD DITA Map//EN" "map.dtd"> <map> <title>Cooking Vegetables.</title> <topichead navtitle="Cooking for Beginners" keyscope="novice"> <topicref href="vegetables.ditamap" format="ditamap"> <ditavalref href="novice.ditaval"/> </topicref> </topichead> <topichead navtitle="Cooking for Experts" keyscope="expert"> <topicref href="vegetables.ditamap" format="ditamap"> <ditavalref href="expert.ditaval"/> </topicref> </topichead> </map> Case 2 - Reusing Common Topics with Different Product NamesLet's say you have a simple DITA task in which you have described how a certain task can be performed for a certain product. In our case, the task describes peeling potatoes: The task works and at some point in your Vegetables Soup publication you realise you need to write a similar task about peeling cucumbers. The task is exactly the same, except the product name. So naturally you want to reuse the existing written task. For this we re-write the task so that instead of of the product potatoes it contains two consecutive profiled product names:Peeling <ph product="potatoes">potatoes</ph><ph product="cucumbers">cucumbers</ph>and include the task in the main DITA Map in two places with different ditaval filters applied:<!DOCTYPE map PUBLIC "-//OASIS//DTD DITA Map//EN" "map.dtd"> <map> <title>Peeling Vegetables.</title> <topichead navtitle="Potatoes"> <topicref href="peeling.dita"> <ditavalref href="potatoes.ditaval"/> </topicref> </topichead> <topichead navtitle="Cucumbers"> <topicref href="peeling.dita"> <ditavalref href="cucumbers.ditaval"/> </topicref> </topichead> </map> This kind of usage will produce in the HTML output folder two topic HTML files from the single peeling.dita, one for each filter context. The DITA samples for this post can be downloaded from http://www.oxygenxml.com/forum/files/branchFilteringBlogSamples.zip. As usual any feedback is welcomed. If you would like to beta test Oxygen XML Editor 17.1 with experimental DITA 1.3 support please contact us: support(a)oxygenxml.com. -- You are subscribed to email updates from "oXygen XML Editor Blog." 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

Odd webhelp with feedback error message
by Jim Henderson 01 Sep '15

01 Sep '15

I'm receiving the following e-mail from a testing server that I'm using feedback on: [73.53.13.170] - 2015-08-26 10:27:46: Unknown error type: [8] Undefined property: RecordSet::$m_CurrentRow on line 200 in file /var/www/html/PingID-API/oxygen-webhelp/resources/php/classes/db/RecordSet.php , PHP 5.4.16 (Linux) This happens when I submit a comment in the comment system. Doesn't seem to matter if I'm authenticated or not. I've tried this on CentOS 7.0 and SUSE Linux Enterprise 11 SP3, and both of them are generating this message for some reason. The output was generated with Oxygen 17. I've got other webhelp with feedback that works OK (in fact, I can use the same output set on another server and it works just fine). I've got mysql installed and the php mysql extension is present as well. I've set up the database fine, and I can see the comments in the UI, but the e-mails being sent only contain this error. I'm not even sure where to start to troubleshoot this - anyone have any ideas? 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/>

2 3

About oXygen XML Editor
by About oXygen XML Editor 28 Aug '15

28 Aug '15

About oXygen XML Editor /////////////////////////////////////////// DITA 1.3 Implementation Status in upcoming Oxygen XML Editor 17.1 Posted: 26 Aug 2015 10:48 PM PDT http://feedproxy.google.com/~r/AboutOxygenXmlEditor/~3/yUZ8D06g8Zo/dita-13-… We plan to release Oxygen 17.1 in about a month or two, probably at the beginning of October this year. Starting with version 17.1, Oxygen includes experimental support for editing and publishing using some of the DITA 1.3 features. If you want to test this support and give us feedback please contact us directly to obtain an Oxygen 17.1 beta kit. To enable DITA 1.3 editing support in Oxygen 17.1 and use the custom bundled DITA Open Toolkit 2.1 for publishing, open the Preferences dialog box, go to DITA, and select the Built-in DITA OT 2.x radio button. The following table is a list of DITA 1.3 features and their implementation status: DITA 1.3 Features Implementation Status Feature Editing Publishing [Latest DITA Open Toolkit 2.x is used.] DITA 1.3 DTD, XML Schema, and Relax NG-based maps/topics/tasks/references, etc. New DITA 1.3 file templates. Also by default DITA topics and maps which do not specify version in the DOCTYPE declaration are also considered to be DITA 1.3. Specific annotations presented in the content completion window and documentation tooltips for all new DITA 1.3 elements. See below Learning Object and Group maps New file templates No specific support implemented Troubleshooting specialization Create and edit new troubleshooting topics No specific support implemented XML markup domain Validation and Content Completion Special rendering in PDF and XHTML-based outputs. Equation and MathML domain Validation and content completion Display and Insert equations Special rendering in PDF and XHTML-based outputs. SVG domain Validation and content completion Display referenced SVG content Special rendering in PDF and XHTML-based outputs. Other new DITA 1.3 elements (div, strike-through, overline, etc) Validation and Content Completion. Special rendering in PDF and XHTML-based outputs. Release management domain Validation and Content Completion No specific support implemented. Scoped keys Define key scopes Validate and check for completeness Resolve keyrefs and conkeyrefs taking key scopes into account. Partially implemented. Various issues may still be encountered. Branch filtering Display, create and edit ditavalref elements. Partially implemented. Various issues may still be encountered. Shorthand to address syntax that identifies elements in the same topic Properly resolved for validation, links, and conrefs. Implemented. Various table attributes (orientation, rotation, scope, and headers on cells) Not implemented in the Table Properties action support. But attributes can be changed from the Attributes view. Not implemented. New Map topicref attributes (cascade, deliveryTarget) Allow setting new attributes, propose proper values for them. Implemented. -- 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

bug report: repeated schema-declared element content
by Syd Bauman 26 Aug '15

26 Aug '15

Assignment: write a RELAX NG schema for Keats _On first looking into Chapman's Homer_. I (deliberately) wrote a ridiculously literalist schema, attached. When I create a new XML document that uses this schema, oXygen properly inserts the required elements, including all 14 required <pLine> elements. When I ask for auto-completion (CTL-space) of the <head> or any of the @n, oXygen does the right thing and gives me the one and only correct choice as the only possible value in the pop-up. But when I ask for auto-completion of <pLine>s 2 through 14, the one and only possible value in the pop-up is the content for the first <pLine>! Worth noting that jing gets it right. After filling in the content using auto-completion, validation will say of <pLine> 2, e.g., character content of element "pLine" invalid; must be equal to "And many goodly states and kingdoms seen;" Details: <oXygen/> XML Developer 17.0, build 2015052917 Mac OS X 10.6.8 error occurs using XML syntax or compact syntax Also tested on: <oXygen/> XML Developer 17.0, build 2015051321 Ubuntu 12.04 only tested compact syntax start = element poem { element head { "On first looking into Chapman's Homer" }, element sonnet { element pLine { attribute num { "01" }, "Much have I travell'd in the realms of gold," }, element pLine { attribute num { "02" }, "And many goodly states and kingdoms seen;" }, element pLine { attribute num { "03" }, "Round many western islands have I been" }, element pLine { attribute num { "04" }, "Which bards in fealty to Apollo hold." }, element pLine { attribute num { "05" }, "Oft of one wide expanse had I been told" }, element pLine { attribute num { "06" }, "That deep-brow'd Homer rules as his demesne;" }, element pLine { attribute num { "07" }, "Yet did I never breathe its pure serene" }, element pLine { attribute num { "08" }, "Till I heard Chapman speak out loud and bold:" }, element pLine { attribute num { "09" }, "Then felt I like some watcher of the skies" }, element pLine { attribute num { "10" }, "When a new planet swims into his ken;" }, element pLine { attribute num { "11" }, "Or like stout Cortez when with eagle eyes" }, element pLine { attribute num { "12" }, "He star'd at the Pacific — and all his men" }, element pLine { attribute num { "13" }, "Look'd at each other with a wild surmise —" }, element pLine { attribute num { "14" }, "Silent, upon a peak in Darien." } } } -- Syd Bauman, EMT-Paramedic Senior XML Programmer/Analyst Northeastern University Women Writers Project s.bauman(a)neu.edu or Syd_Bauman(a)alumni.Brown.edu

4 5

About oXygen XML Editor
by About oXygen XML Editor 25 Aug '15

25 Aug '15

About oXygen XML Editor /////////////////////////////////////////// DITA 1.3 Key Scopes - Next Generation of Reuse Posted: 24 Aug 2015 03:34 AM PDT http://feedproxy.google.com/~r/AboutOxygenXmlEditor/~3/eupu2DkD4is/dita-13-… Thanks to the hard working OASIS DITA TC Group the DITA 1.3 standard is quite close to being released. Oxygen 17.1 which will be released probably in September this year will have experimental DITA 1.3 support. This will include publishing using a custom build of the latest DITA Open Toolkit 2.x engine in which the main developer Jarno Elovirta has already added incipient support for key scopes and branch filtering. In this blog post I'm going to give you a small example of how key scopes can benefit simple cases of reuse which could not be done previously. Let's say you have a simple DITA task in which you have described how a certain task can be performed for a certain product. In our case, the task describes peeling a potato: The task works and at some point in your Vegetables Soup publication you realise you need to write a similar task about peeling cucumbers. The task is exactly the same, except the product name. So naturally you want to reuse the existing written task. For this we re-write the task so that instead of of the product potatoes it contains a key reference:<ph keyref="vegetable"/> Next we need to define in our DITA Map the vegetable key and bind it to a specific value in the potatoes context: <topicref href="potatoes_overview.dita" keyscope="potatoes">  <keydef keys="vegetable"> <topicmeta> <keywords> <keyword>potatoes</keyword> </keywords> </topicmeta> </keydef>  <topicref href="peeling.dita"/> </topicref>and add in our DITA Map another key scope with the overview and the task which deal with cucumbers peeling: <topicref href="cucumbers_overview.dita" keyscope="cucumbers">  <keydef keys="vegetable"> <topicmeta> <keywords> <keyword>cucumbers</keyword> </keywords> </topicmeta> </keydef>  <topicref href="peeling.dita"/> </topicref> As you may have noticed, we have not used the key scope names for anything. Just by defining the key scopes, we made the product name to be expanded differently in both contexts. But our Vegetables Soup publication may also contain a topic which lists all possible vegetables. This topic is defined in a context outside any key scope:<topicref href="vegetables_over.dita"/>and this overview topic can refer to each product name using the full keyscope key reference value:<!DOCTYPE topic PUBLIC "-//OASIS//DTD DITA Topic//EN" "topic.dtd"> <topic id="vegetables_over"> <title>Vegetables Overview</title> <body> <p>This is an overview of all vegetables necessary to make soup. You will learn how to use vegetables like <ph keyref="potatoes.vegetable"/> and <ph keyref="cucumbers.vegetable"/> to make a great starter soup.</p> </body> </topic> As stated before, this kind of reuse was not possible using the standard DITA 1.2 standard constructs. As it turns out, with DITA 1.3 we can also implement this kind of reuse using branch filtering. The DITA samples for this post can be downloaded from http://www.oxygenxml.com/forum/files/keyscopesBlogSamples.zip. As usual any feedback is welcomed. If you would like to beta test Oxygen XML Editor 17.1 with experimental DITA 1.3 support please contact us to support(a)oxygenxml.com. -- 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