Date   

SCORM output for DITA sources

Prof. Sissi Closs
 

Dear DITA users,

 

Does anybody know a possibility to produce SCORM output from DITA sources (tagged with DITA learning).

 

Br, Sissi


Copying an internal link for a new browser, using a right-click. Is it possible?

Scott Barney
 

The issue:

Our support wants to be able to right-click on an internal link, and end up with a URL that can be pasted in a separate browser, to bring the reader to a specific section of the page.

The link is being created as a cross reference link in the DITA file:
 <xref href="r_fgl_errors_001.dita#r_fgl_errors_001/error-250"><msgnum>-250</msgnum></xref>

In our HTML output (DITA-OT and Oxygen WebHelp):
- If I click on the link, I am taken to the correct page, scrolled to the linked-to section. Which is to be expected, that it how it is designed to work.
- If I right-click and copy that link, then paste into another browser, it *flashes* to the right section -- but then the URL rewrites itself to be the URL of the page itself and I am taken to the top of the page.

For example, with the code above:
- The right-click pastes this link:
   https://intranet.xxx.com/distrib/manuals/FOURJS/FJSONLY/trunk/fjs-fgl-latest-manual-html-draft/fgl-topics/r_fgl_errors_001.html#r_fgl_errors_001__error-250

- After the paste, and the flash of where I want to be, the URL is rewritten to be:
  https://intranet.xxx.com/distrib/manuals/FOURJS/FJSONLY/trunk/fjs-fgl-latest-manual-html-draft/index.html#fgl-topics/r_fgl_errors_001.html 
  And we are taken to the top of the page.

Has anyone needed to solve this issue, and if so, how did you do it?


Markdown with abbreviated-form

Nicholas Mucks
 

Hi folks!

We’re looking at how to map some content models from dita to markdown. One of them is glossaries and inline references to the abbreviated-form element. We’d like to use markdown but still use glossary keys to get the surface form on first usage and the abbreviated form thereafter.

We like how the topic types work with the pandoc headers so that we can still get task labels and whatnot. Is pandoc usable to name the element as well, such as abbreviated-form with a key reference?

Has anyone done this?

Thanks!

Take care,
- Nick

Sent from mobile


Re: Can't link into conref? unstable ids

Stuart Norton <snorton@...>
 

Thank you very much for pointing out the issue.

 

Somewhat surprisingly, I am not the same as the person who reported the problem there – good to know I'm not alone I guess. :-)

 

We will follow up further in GitHub.

 

Best regards,

Stuart

 

 

Juniper Business Use Only

From: main@dita-users.groups.io <main@dita-users.groups.io> On Behalf Of Radu Coravu
Sent: Wednesday, April 28, 2021 12:18 AM
To: main@dita-users.groups.io; dita-users@groups.io
Subject: Re: [dita-users] Can't link into conref? unstable ids

 

[External Email. Be cautious of content]

 

Hi Stuart,

About your questions:

  1. What if we overrode the id attribute generation to avoid the auto-generated unique values, and we occasionally had a duplicate id? Are there some dangers of having duplicate ids that I am missing – e.g. perhaps it could break the TOC?

From what I remember such problems do not break the publishing.

  1. Are there any other options that we have - other than reorganizing all of our content so we don't ever need to link to locations inside of conrefs?

I answered you here, I assume you added this issue to the DITA OT issues list:

https://github.com/dita-ot/dita-ot/issues/3736#issuecomment-828209386

Regards,

Radu

Radu Coravu
Oxygen XML Editor

On 4/28/21 00:50, Stuart Norton via groups.io wrote:

Dear DITA users,

 

We've discovered a behavior in DITA OT processing that looks like it's going to cause us big problems. We would really appreciate your advice.

 

The problem that we are seeing is that when we publish a document containing a conref (to HTML), the content inside that conref has its id attributes rewritten with more-or-less random values that can change unpredictably when the document is updated. For example:

id="request-system-reboot-command__d5358e39"

(the d### characters in bold are the ones that update randomly).

 

We have many external links that point into conrefed content. As a result of this behavior, those links are often breaking when we republish the documents.

 

It looks like this behavior is by design, and it happens in this step: https://www.dita-ot.org/dev/reference/preprocess-conref.html.  That step is intended to "ensure that the values of the id attribute within the referencing topic remain unique." But in our experience so far, I would say that the potential danger of having a duplicate id on an HTML page seem *much* more acceptable than having many external links break when we republish a document.

 

Questions:

  1. What if we overrode the id attribute generation to avoid the auto-generated unique values, and we occasionally had a duplicate id? Are there some dangers of having duplicate ids that I am missing – e.g. perhaps it could break the TOC?
  2. Are there any other options that we have - other than reorganizing all of our content so we don't ever need to link to locations inside of conrefs?

 

Thanks in advance for your thoughts/assistance.

 

Best regards,

Stuart

 

 

Juniper Business Use Only

 


Re: Can't link into conref? unstable ids

Radu Coravu
 

Hi Stuart,

About your questions:

  1. What if we overrode the id attribute generation to avoid the auto-generated unique values, and we occasionally had a duplicate id? Are there some dangers of having duplicate ids that I am missing – e.g. perhaps it could break the TOC?
From what I remember such problems do not break the publishing.
  1. Are there any other options that we have - other than reorganizing all of our content so we don't ever need to link to locations inside of conrefs?

I answered you here, I assume you added this issue to the DITA OT issues list:

https://github.com/dita-ot/dita-ot/issues/3736#issuecomment-828209386

Regards,

Radu

Radu Coravu
Oxygen XML Editor
On 4/28/21 00:50, Stuart Norton via groups.io wrote:

Dear DITA users,

 

We've discovered a behavior in DITA OT processing that looks like it's going to cause us big problems. We would really appreciate your advice.

 

The problem that we are seeing is that when we publish a document containing a conref (to HTML), the content inside that conref has its id attributes rewritten with more-or-less random values that can change unpredictably when the document is updated. For example:

id="request-system-reboot-command__d5358e39"

(the d### characters in bold are the ones that update randomly).

 

We have many external links that point into conrefed content. As a result of this behavior, those links are often breaking when we republish the documents.

 

It looks like this behavior is by design, and it happens in this step: https://www.dita-ot.org/dev/reference/preprocess-conref.html.  That step is intended to "ensure that the values of the id attribute within the referencing topic remain unique." But in our experience so far, I would say that the potential danger of having a duplicate id on an HTML page seem *much* more acceptable than having many external links break when we republish a document.

 

Questions:

  1. What if we overrode the id attribute generation to avoid the auto-generated unique values, and we occasionally had a duplicate id? Are there some dangers of having duplicate ids that I am missing – e.g. perhaps it could break the TOC?
  2. Are there any other options that we have - other than reorganizing all of our content so we don't ever need to link to locations inside of conrefs?

 

Thanks in advance for your thoughts/assistance.

 

Best regards,

Stuart

 


Juniper Business Use Only


  


Can't link into conref? unstable ids

Stuart Norton <snorton@...>
 

Dear DITA users,

 

We've discovered a behavior in DITA OT processing that looks like it's going to cause us big problems. We would really appreciate your advice.

 

The problem that we are seeing is that when we publish a document containing a conref (to HTML), the content inside that conref has its id attributes rewritten with more-or-less random values that can change unpredictably when the document is updated. For example:

id="request-system-reboot-command__d5358e39"

(the d### characters in bold are the ones that update randomly).

 

We have many external links that point into conrefed content. As a result of this behavior, those links are often breaking when we republish the documents.

 

It looks like this behavior is by design, and it happens in this step: https://www.dita-ot.org/dev/reference/preprocess-conref.html.  That step is intended to "ensure that the values of the id attribute within the referencing topic remain unique." But in our experience so far, I would say that the potential danger of having a duplicate id on an HTML page seem *much* more acceptable than having many external links break when we republish a document.

 

Questions:

  1. What if we overrode the id attribute generation to avoid the auto-generated unique values, and we occasionally had a duplicate id? Are there some dangers of having duplicate ids that I am missing – e.g. perhaps it could break the TOC?
  2. Are there any other options that we have - other than reorganizing all of our content so we don't ever need to link to locations inside of conrefs?

 

Thanks in advance for your thoughts/assistance.

 

Best regards,

Stuart

 


Juniper Business Use Only


Re: Anyone using Oxygen XML Editor to generate WebHelp output from DITA content?

Radu Coravu
 

Thanks Leigh :)

On 4/27/21 17:18, Leigh White wrote:
Hi Radu,

The IXIASOFT online documentation is Oxygen WebHelp output with IXIASOFT styling. We love the ease of publishing. Here's one example:

https://www.ixiasoft.com/documentation/IXIASOFT_CCMS/6.3/User_Guides_Writer_DRM/en/index.html

Best,
Leigh
-- 
Radu Coravu
Oxygen XML Editor


Re: Anyone using Oxygen XML Editor to generate WebHelp output from DITA content?

Leigh White
 

Hi Radu,

The IXIASOFT online documentation is Oxygen WebHelp output with IXIASOFT styling. We love the ease of publishing. Here's one example:

https://www.ixiasoft.com/documentation/IXIASOFT_CCMS/6.3/User_Guides_Writer_DRM/en/index.html

Best,
Leigh


Re: Conditional Attribute Groups

Michael McLoughlin
 

Thanks for that Radu. You clearly have more fine-grained control with Subject Scheme maps.


Re: Conditional Attribute Groups

Radu Coravu
 

Hi Michael,

My take on this:

One thing better about using subject schemes to impose attribute values is that you automatically receive a validation error in Oxygen if you set the wrong value to an attribute, so the subject scheme controlled set of values is imposed when editing your content.

It's also beneficial I think to have the controlled values defined inside the DITA Project's content, so even if you do not use a special framework in Oxygen you get the same benefits from the controlled values.

Also Subject Scheme map defined values can influence the filtering stage when you publish:

https://www.oxygenxml.com/doc/versions/23.1/ug-editor/topics/subject-scheme-map.html#subject-scheme-map__using_a_subject_scheme_in_conjuction_with_a_ditav

Regards,

Radu

Radu Coravu
Oxygen XML Editor
On 4/27/21 10:53, Michael McLoughlin wrote:

Out of interest John, what's the benefit of using subject scheme maps in Oxygen over customizing the Oxygen cc_config,xml? We use the latter to control element, attribute and attribute value choice.

  


Re: Conditional Attribute Groups

Michael McLoughlin
 

Out of interest John, what's the benefit of using subject scheme maps in Oxygen over customizing the Oxygen cc_config,xml? We use the latter to control element, attribute and attribute value choice.


Re: Conditional Attribute Groups

john.kirkilis@...
 

The only thing I've done with subjectschemes is to demo a proof of concept to control valid values for conditional attributes. The subjectscheme maps can then be shared so all writers are honoring the same conditional processing logic for common cases, which is particularly relevant when content is reused across independent product repos using Git Submodules or other means. Oxygen uses the subjectscheme maps to control which values are presented in content completion popups and the Attributes view.

Besides DITA's provisions for filtering attributes for conditional content processing, have you also had the desire to filter by any of the topic metadata elements, such as category, featnum, or even othermeta? Has anyone added this capability to their own workflow, either in a pre or post processing phase to DITA-OT?

Metadata elements make their way into HTML output to allow the reader to filter or do faceted search at "browse time". It would seem natural to  allow a writer to have the option to do the same at build time to define specific deliverables.

Metadata elements have their own attributes. For example, <audience> has @type, @job, @experiencelevel, etc., which wouldn't quite fit the conditional attribute model. Without resorting to specialization, perhaps conditional attribute groups could be used to emulate these cases with @audience="job(operator) experiencelevel(advanced)". It would be possible to then use Schematron or the Oxygen SDK to keep the metadata elements and attribute groups in sync to some degree, where a change in one updates the other and any differences could be caught and quickfixes offered.

It could be handy if these currently orthogonal uses of "metadata" could be unified.


Re: Anyone using Oxygen XML Editor to generate WebHelp output from DITA content?

Radu Coravu
 

Hi Christina,

Thank you :)

Regards,

Radu

Radu Coravu
Oxygen XML Editor
On 4/24/21 13:19, stinakab via groups.io wrote:

Hi Radu,

You know ours already, but for the rest of the group: you're welcome to check out our latest public output layout on https://steinberg.help/nuendo/v11/en/index.html, made with Oxygen 23.0 and DITA OT 3.5.4, with accessibility in mind.
We have several layout versions of the webhelp output in our documents archive. The latest one is the one we are most proud of - for the moment. There are always new things to add.
We think the output gets better and better with every version. Thanks to the SyncRO Soft team.

Christina

  


Re: Job opportunity at Puppet: US Remote #jobhunting

Michael McLoughlin
 

I'm not the hiring manager so I'm afraid I can't say. From my own experience though, if you mention in interview what you need, Puppet are very good at making a sensible offer.


Re: Override Topic title with @navtitle #XSLT

Shaurabh
 

Hi all,

We are using DITA-OT version 3.5.4. Any further suggestion on this topic will be really helpful.


Thanks,
Shaurabh


Re: Job opportunity at Puppet: US Remote #jobhunting

Aaron Mehl
 

Hi I am interested to know what your are offering?

Aaron

On Tuesday, April 20, 2021, 02:20:55 PM EDT, Michael McLoughlin <michael.mcloughlin@...> wrote:


Puppet have an open position for a tech writer with DITA and OxygenXML Author experience anywhere in the US:

https://www.linkedin.com/jobs/view/2493166374/?refId=xhuqco0kmr6eD5N%2BoOIO%2FQ%3D%3D&trackingId=fxCzkB4xHvauEHyRBqCNXg%3D%3D
--
Michael McLoughlin
Senior Technical Writer
Puppet


Re: Anyone using Oxygen XML Editor to generate WebHelp output from DITA content?

stinakab
 

Hi Radu,

You know ours already, but for the rest of the group: you're welcome to check out our latest public output layout on https://steinberg.help/nuendo/v11/en/index.html, made with Oxygen 23.0 and DITA OT 3.5.4, with accessibility in mind.
We have several layout versions of the webhelp output in our documents archive. The latest one is the one we are most proud of - for the moment. There are always new things to add.
We think the output gets better and better with every version. Thanks to the SyncRO Soft team.

Christina


Re: #DITA-OT - Migrating from OT-1.8 to 3.5 #DITA-OT

MarkH
 

Thanks, Mica, I'm beginning to think that would be a better way to go. Even the first move to 2.0 is giving me trouble and it seems like a lot of needless aggravation to go through the 12 steps needed to get to 3.5. One thing is for sure, when I get this done, I will be more inclined to keep it up to date!


Re: #DITA-OT - Migrating from OT-1.8 to 3.5 #DITA-OT

Mica Semrick
 

Hi Mark,

I did this fairly recently and decided it was best to just start over with a fresh 3.x plugin and reimplement the changes that were made to the original plugin.

Things have changed quite a bit, and I didn't feel it was worth it to make the plugin work with the whole 2.x dita-ot series.

-m


On April 23, 2021 12:12:11 PM PDT, MarkH <mark@...> wrote:
Hi!

I have been tasked with migrating our custom webhelp plugin which was written for DITA-OT 1.8.4, to DITA-OT 3.5. From what I have read about the process, I really need to start by migrating to 2.0, then working my way up through the various versions (2.1, 2.2, 2.3, etc.). Any advice, tips, tricks, warnings, or suggestions about how best to proceed would be appreciated!

Thank you in advance!


Re: Anyone using Oxygen XML Editor to generate WebHelp output from DITA content?

Chris Papademetrious
 

Hi Radu,

I hope there are on-group replies to your request. We are quite interested in having a look.

 - Chris

141 - 160 of 46324