Date   

Re: Chunking and topic titles

Michael McLoughlin
 

Did you try an explicit toc="yes" in the T1 topicref?


Chunking and topic titles

Nancy Roberts
 

Hi,

I've got a map with two topics - a concept (C1) and a task (T1). C1 and T1 are siblings. I want to chunk the entire thing. I placed chunk="to-content" at the map level, and it chunked as expected. However, the output only contains the topic title for C1. There's no topic title for T1. What do I do to make the T1 title appear in the middle of the chunk?

Thanks,
Nancy

Nancy Roberts
Varonis


Re: DITA-OT normalization plugin behavior

Radu Coravu
 

Hi Alan,

Maybe you can take a look also at this older Oxygen forum thread:

https://www.oxygenxml.com/forum/post61981.html

Regards,

Radu

Radu Coravu
Oxygen XML Editor

On 5/20/21 19:27, Alan Houser wrote:
Colleagues,

I'm trying to figure out whether behavior I'm seeing from the DITA-OT normalization plugin is by design.

I have a parent map, with maprefs to other maps. The referenced maps include map-level metadata in <topicmeta>.

After DITA-OT normalization, the maprefs are resolved, and the parent map references all resolved topics directly (as expected). But since the parent map no longer references the child maps, the map-level metadata on the child maps is essentially unavailable for further processing. (The child maps are also normalized and copied to the output folder, but there's no longer a relationship between the original "parent" and child maps).

Of course, I need the map-level metadata on the child maps. And I don't see a normalization option for "don't resolve maprefs".

If I'm missing an option, approach, or explanation, I would be grateful to hear it.

-Alan


Re: DITA-OT normalization plugin behavior

Alan Houser
 

Hi Nick,

Thank you! I actually know what these things mean.  :-) Appreciated!

-Alan

On 5/22/21 1:51 PM, Nicholas Mucks via groups.io wrote:
Hi Alan,
Easy. You can extend the dita normalization plugin but skip certain modules in processing by initializing build parameters based on the steps you don’t want to perform.

Take care,
- Nick

Sent from mobile

On May 22, 2021, at 8:44 AM, Alan Houser <arh@groupwellesley.com> wrote:

A follow-up to this question, about which I acknowledge that I've done zero research ...

What's the level of difficulty of writing a plugin that does "just filtering", or "just conref resolution"; producing clean DITA source files that mimic the originals (modulo filtering and/or conref resolution)? Use case would be to hand off DITA source to a partner or to another processing chain.

-Alan

On 5/20/21 12:27 PM, Alan Houser wrote:
Colleagues,

I'm trying to figure out whether behavior I'm seeing from the DITA-OT normalization plugin is by design.

I have a parent map, with maprefs to other maps. The referenced maps include map-level metadata in <topicmeta>.

After DITA-OT normalization, the maprefs are resolved, and the parent map references all resolved topics directly (as expected). But since the parent map no longer references the child maps, the map-level metadata on the child maps is essentially unavailable for further processing. (The child maps are also normalized and copied to the output folder, but there's no longer a relationship between the original "parent" and child maps).

Of course, I need the map-level metadata on the child maps. And I don't see a normalization option for "don't resolve maprefs".

If I'm missing an option, approach, or explanation, I would be grateful to hear it.

-Alan
--
Alan Houser
Group Wellesley, Inc.
Consultant and Trainer, Technical Publishing
arh on Twitter
412-450-0532


Re: DITA-OT normalization plugin behavior

Nicholas Mucks
 

Hi Alan,
Easy. You can extend the dita normalization plugin but skip certain modules in processing by initializing build parameters based on the steps you don’t want to perform.

Take care,
- Nick

Sent from mobile

On May 22, 2021, at 8:44 AM, Alan Houser <arh@groupwellesley.com> wrote:

A follow-up to this question, about which I acknowledge that I've done zero research ...

What's the level of difficulty of writing a plugin that does "just filtering", or "just conref resolution"; producing clean DITA source files that mimic the originals (modulo filtering and/or conref resolution)? Use case would be to hand off DITA source to a partner or to another processing chain.

-Alan

On 5/20/21 12:27 PM, Alan Houser wrote:
Colleagues,

I'm trying to figure out whether behavior I'm seeing from the DITA-OT normalization plugin is by design.

I have a parent map, with maprefs to other maps. The referenced maps include map-level metadata in <topicmeta>.

After DITA-OT normalization, the maprefs are resolved, and the parent map references all resolved topics directly (as expected). But since the parent map no longer references the child maps, the map-level metadata on the child maps is essentially unavailable for further processing. (The child maps are also normalized and copied to the output folder, but there's no longer a relationship between the original "parent" and child maps).

Of course, I need the map-level metadata on the child maps. And I don't see a normalization option for "don't resolve maprefs".

If I'm missing an option, approach, or explanation, I would be grateful to hear it.

-Alan
--
Alan Houser
Group Wellesley, Inc.
Consultant and Trainer, Technical Publishing
arh on Twitter
412-450-0532






Re: DITA-OT normalization plugin behavior

Alan Houser
 

A follow-up to this question, about which I acknowledge that I've done zero research ...

What's the level of difficulty of writing a plugin that does "just filtering", or "just conref resolution"; producing clean DITA source files that mimic the originals (modulo filtering and/or conref resolution)? Use case would be to hand off DITA source to a partner or to another processing chain.

-Alan

On 5/20/21 12:27 PM, Alan Houser wrote:
Colleagues,

I'm trying to figure out whether behavior I'm seeing from the DITA-OT normalization plugin is by design.

I have a parent map, with maprefs to other maps. The referenced maps include map-level metadata in <topicmeta>.

After DITA-OT normalization, the maprefs are resolved, and the parent map references all resolved topics directly (as expected). But since the parent map no longer references the child maps, the map-level metadata on the child maps is essentially unavailable for further processing. (The child maps are also normalized and copied to the output folder, but there's no longer a relationship between the original "parent" and child maps).

Of course, I need the map-level metadata on the child maps. And I don't see a normalization option for "don't resolve maprefs".

If I'm missing an option, approach, or explanation, I would be grateful to hear it.

-Alan
--
Alan Houser
Group Wellesley, Inc.
Consultant and Trainer, Technical Publishing
arh on Twitter
412-450-0532


Re: DITA-OT normalization plugin behavior

Alan Houser
 

Reece,

Thank you for confirming this behavior and suggesting a work-around. Much appreciated!

-Alan

On 5/20/21 4:39 PM, r.roggen wrote:
I can’t say whether the behavior is by design or not, but I’ve experienced it. In my case, to make a submap‘s metadata available for further processing, I wrapped its topics in a topicgroup and put the metadata in the topicgroup instead. That metadata didn’t get dropped.

-Reece

On May 20, 2021, at 11:27 AM, Alan Houser <arh@groupwellesley.com> wrote:

Colleagues,

I'm trying to figure out whether behavior I'm seeing from the DITA-OT normalization plugin is by design.

I have a parent map, with maprefs to other maps. The referenced maps include map-level metadata in <topicmeta>.

After DITA-OT normalization, the maprefs are resolved, and the parent map references all resolved topics directly (as expected). But since the parent map no longer references the child maps, the map-level metadata on the child maps is essentially unavailable for further processing. (The child maps are also normalized and copied to the output folder, but there's no longer a relationship between the original "parent" and child maps).

Of course, I need the map-level metadata on the child maps. And I don't see a normalization option for "don't resolve maprefs".

If I'm missing an option, approach, or explanation, I would be grateful to hear it.

-Alan
--
Alan Houser
Group Wellesley, Inc.
Consultant and Trainer, Technical Publishing
arh on Twitter
412-450-0532


Re: DITA-OT normalization plugin behavior

r.roggen
 

I can’t say whether the behavior is by design or not, but I’ve experienced it. In my case, to make a submap‘s metadata available for further processing, I wrapped its topics in a topicgroup and put the metadata in the topicgroup instead. That metadata didn’t get dropped.

-Reece

On May 20, 2021, at 11:27 AM, Alan Houser <arh@groupwellesley.com> wrote:

Colleagues,

I'm trying to figure out whether behavior I'm seeing from the DITA-OT normalization plugin is by design.

I have a parent map, with maprefs to other maps. The referenced maps include map-level metadata in <topicmeta>.

After DITA-OT normalization, the maprefs are resolved, and the parent map references all resolved topics directly (as expected). But since the parent map no longer references the child maps, the map-level metadata on the child maps is essentially unavailable for further processing. (The child maps are also normalized and copied to the output folder, but there's no longer a relationship between the original "parent" and child maps).

Of course, I need the map-level metadata on the child maps. And I don't see a normalization option for "don't resolve maprefs".

If I'm missing an option, approach, or explanation, I would be grateful to hear it.

-Alan

--
Alan Houser
Group Wellesley, Inc.
Consultant and Trainer, Technical Publishing
arh on Twitter
412-450-0532






DITA-OT normalization plugin behavior

Alan Houser
 

Colleagues,

I'm trying to figure out whether behavior I'm seeing from the DITA-OT normalization plugin is by design.

I have a parent map, with maprefs to other maps. The referenced maps include map-level metadata in <topicmeta>.

After DITA-OT normalization, the maprefs are resolved, and the parent map references all resolved topics directly (as expected). But since the parent map no longer references the child maps, the map-level metadata on the child maps is essentially unavailable for further processing. (The child maps are also normalized and copied to the output folder, but there's no longer a relationship between the original "parent" and child maps).

Of course, I need the map-level metadata on the child maps. And I don't see a normalization option for "don't resolve maprefs".

If I'm missing an option, approach, or explanation, I would be grateful to hear it.

-Alan

--
Alan Houser
Group Wellesley, Inc.
Consultant and Trainer, Technical Publishing
arh on Twitter
412-450-0532


[ANN] Release of XMLmind Word To XML v1.8.4

Hussein Shafie
 

Release of XMLmind Word To XML v1.8.4.

- Minor enhancements and bug fixes.

- XMLmind Word To XML is now officially supported on Java™ 16 platforms).

More information in http://www.xmlmind.com/w2x/changes.html

--------------------------------------
What is XMLmind Word To XML?
--------------------------------------

XMLmind Word To XML can automatically convert DOCX files to:

- Clean, styled, valid HTML (single page or multi-page HTML, Web Help, EPUB) looking very much like the source DOCX file.

- Unstyled, but structured and valid, DITA bookmap, map, topic, DocBook (including V5.1 assembly), XHTML (single page or multi-page HTML, Web Help, EPUB) or XML conforming to your custom schema.

Home Page: http://www.xmlmind.com/w2x/

Download: http://www.xmlmind.com/w2x/download.shtml

Free online DOCX conversion services: http://www.xmlmind.com/w2x/online_w2x.html


Oxygen XML Author - DITA Startup Project

Radu Coravu
 

Hi everyone,

We recently put together on GitHub a "DITA Startup Project" containing a set of DITA editing customizations and structure best practices useful for working on a DITA project with Oxygen XML Author version 23.0 or newer.

This blog post covers all the aspects of the project:

https://blog.oxygenxml.com/topics/startup_dita_project.html

Such a project can be used to share common settings between writers collaborating using version control systems like Git or Subversion, as the project contains both the DITA content and the customization of the DITA editing experience.

I hope Oxygen + DITA users will find some inspiration in this sample project. Also if you have any feedback about it, improvement ideas or change suggestions, they are as usual welcomed.

Regards,

Radu

Radu Coravu
Oxygen XML Editor


Re: Something like ditaval, but for topics or smaller?

despopoulos_chriss
 

Hi Nick...

I'd say it depends.  Again, it's a question of ROI.  It might be more efficient to maintain separate referenced lists where all the items are pointers to the superset.  But that can also get to be a headache, where setting categories in the supersets, and then referencing the superset with a given categorical filter would be much easier.  In fact, category vs individual variation might be the criterion to focus on when deciding whether to use branch filtering vs reference.  Gotta think about that...

cud


Re: Something like ditaval, but for topics or smaller?

Nicholas Mucks
 

Hi!

At this granular of a level, isnt this more of a use case for keys and conkeyref  in the topics than conditions? You can define a warehouse topic or keymap at your rootmap and apply your conditions there, not in the topics.

Take care,
- Nick

Sent from mobile

On May 15, 2021, at 4:55 AM, Chris Papademetrious <chrispitude@...> wrote:

@despopoulos_chriss, you make a good point about ROI.

We like DITAVAL for book-wide profiling, as product conditions are group-wide and stable. But this would not be true for ad-hoc usage. If I make DITAVAL files for "tableA" and "tableB" for one specific book, then later rewrite the content to remove those tables, now I have a dangling DITAVAL file to be noticed and removed.

DITA is mechanically capable of many, many things. Many features are readily accessible to writers in a DITA editor (Oxygen). Perhaps the more mechanically involved features require a CMS to orchestrate the moving pieces. I think what we're discussing here is, could DITA somehow support ad-hoc conditionalization via the former instead of the latter?

 - Chris

P.S. We also use a small fraction of DITA. We specialized it to match the elements in our previous format (structured FrameMaker). We use variables and profiling. We are just starting to explore con[key]ref. We don't use subject schemes, branch filtering, or anything like that.


Re: Something like ditaval, but for topics or smaller?

Chris Papademetrious
 

@despopoulos_chriss, you make a good point about ROI.

We like DITAVAL for book-wide profiling, as product conditions are group-wide and stable. But this would not be true for ad-hoc usage. If I make DITAVAL files for "tableA" and "tableB" for one specific book, then later rewrite the content to remove those tables, now I have a dangling DITAVAL file to be noticed and removed.

DITA is mechanically capable of many, many things. Many features are readily accessible to writers in a DITA editor (Oxygen). Perhaps the more mechanically involved features require a CMS to orchestrate the moving pieces. I think what we're discussing here is, could DITA somehow support ad-hoc conditionalization via the former instead of the latter?

 - Chris

P.S. We also use a small fraction of DITA. We specialized it to match the elements in our previous format (structured FrameMaker). We use variables and profiling. We are just starting to explore con[key]ref. We don't use subject schemes, branch filtering, or anything like that.


Re: Something like ditaval, but for topics or smaller?

despopoulos_chriss
 

First, thanks to Kris for cluing me in. 

If ignoruntz is bliss, I have blissfully been using as little as possible of DITA these past 7 or so years.  In fact, we use close to the equivalent of LwDITA.  Which makes me wonder, does LwDITA support branch filtering?  (I'm guessing not...  Just wondering, no implications.)

@Chris, I feel your pain.  I was kind of hoping for something similar to your idea of internal profiling.  Maybe something like
<div profileBase="audience" exclusions="foo bar baz">
  <ul conref="supersetList"><li/></ul>
</div>

For us, it would be a bit of a hassle to use branch filtering, because we implement our own DITA rendering.  But I could pretty easily build a data object that maps individual topics to their branched filters, and add that data to the params we pass as we transform each topic. 

One thing I'm wondering is where the ROI threshold is for this.  Assuming a superset that needs to be sliced and diced into subsets, is there some threshold where it would just be easier to conref the individual items rather than filter the superset list?  Also, how does this work if the filtering requirements change...  Does that make it even more complicated?  We support groups of "technologies" that each have different subsets of "features".  We want to track the superset list, and present it when we discuss the "category" of technology.  But each instance needs a correct list.  What happens when the support for one instance changes?  What happens when we add a new instance?  Is there a threshold where tracking this via metadata will become unsustainable?  That will be what determines how we do this...

Anyway, thanks for the info.


[ANN] Release of open source XMLmind DITA Converter v3.8.2

Hussein Shafie
 

Release of open source XMLmind DITA Converter v3.8.2.

Maintenance release: upgraded software component XMLmind Web Help Compiler to version 3.2; tested ditac against Java™ 16.

More information in http://www.xmlmind.com/ditac/changes.html

--------------------------------------------------------------
What is XMLmind DITA Converter?
--------------------------------------------------------------

XMLmind DITA Converter (ditac for short) is a serious alternative to the
DITA Open Toolkit.

Out of the box, ditac allows to convert the most complex DITA 1.0, 1.1,
1.2 and 1.3 documents to production-quality XHTML 1.0, XHTML 1.1, HTML
4.01, (X)HTML 5, Web Help, Java™ Help, HTML Help, Eclipse Help, EPUB 2,
EPUB 3, PDF, PostScript®, RTF, WordprocessingML (Word 2003+), Office
Open XML (.docx, Word 2007+), OpenDocument (.odt, OpenOffice/LibreOffice
2+).

Like the DITA OT, ditac is free, open source, software.

http://www.xmlmind.com/ditac/


Declarative Amsterdam 2021, Call for Presentations

 

Declarative Amsterdam 2021, Call for Presentations
 
On 4 and 5 November 2021, the third Declarative Amsterdam conference will take place at CWI, Science Park, Amsterdam.
 
The conference focuses on the technologies and methods used for declarative programming and declarative data.
 
Declarative programming (https://en.wikipedia.org/wiki/Declarative_programming) is a style of programming that expresses the logic of computation without describing its control flow.  It allows you to focus on the 'what' of a program, rather than the 'how'. Declarative programs can be constructed in a fraction of the time, using much less code than a traditional computer program. Declarative methods for programming and data modelling can help avoid making the mistakes that have lead to failing software projects for several decades.
 
Declarative Amsterdam will have presentations on past experiences, current trends and future perspectives in fields such as functional programming, declarative data modelling, databases, XML and related technologies, JSON, CSS, semantic web, data science, data visualization, grammars, parsing, and domain-specific languages.

We anticipate by November that we will be able to hold the conference face-to-face, but either way, we are planning to broadcast live as well.
 
The first day will feature tutorials, combining presentations and hands-on sessions to give an introduction to specific topics.

The second day is a symposium, and will consist of shorter presentations.  Speakers can discuss new ideas, frameworks, applications of declarative methods, and best practices.
 
Call for Presentations
 
We invite practitioners, software architects and engineers, academic researchers and others to submit a proposal for a tutorial or a presentation.
 
Tutorials can be between 1.5 and 2.5 hours, and preferably include hands-on sessions for participants. Presentations on the second day can be between 20 and 45 minutes. We plan to create the possibility of online presentation via video.
 
Proposals should at least include a title, duration and summary (90 - 200 words), but may also be a full paper. Speakers have the option of submitting a full paper or slides, to be published on the Declarative Amsterdam website.
 
Please send proposals to call@...
 
Timeline
 
Submission deadline: 31 July
Acceptance: Beginning of September
Conference: 4/5 November.

For papers and topics from previous years, see the website:
http://declarative.amsterdam/

 


Re: Something like ditaval, but for topics or smaller?

Chris Papademetrious
 

Hi Kris, Chris, (!!)

Our team has been using DITA for almost two years. Our writers are just now getting comfortable working with maps via Oxygen's GUI. The creation and use of DITAVAL files is well beyond their comfort level. (We do use DITAVAL files for @product filtering, but I maintain those and the writers don't know the details.)

I have wished for a more ad-hoc form of filtering that (1) uses attributes instead of files to locally impose a condition, and (2) works for both map and topic elements. For example, something like this:

<profiling audience="foo">
  <ul conref="supersetList"><li/></ul>
</profiling>

where the attribute values of a <profiling> element *apply* conditions, rather than being affected by them. (I don't claim to have thought through all the details...)

About six months ago, I had a user who wanted to reuse the same table in two places in their book, but a subset of rows in each location (just like Chris's question). Asking the writer to use DITAVAL was not an option. There wasn't even an obvious profiling attribute to use. Maybe @audience="table1" and @audience="table2"?

So although DITA was mechanically capable of the request, the writer mechanics weren't feasible. They ended up duplicating and modifying the table. It made me sad.

 - Chris


Re: Publishing DITA content to knowledge bases

Chris Papademetrious
 

Hi Radu,

We upload our HTML OLH content to an AWS server, then make it accessible to our users via a Salesforce/Coveo portal.

 - Chris


Re: Need new DITA CMS - Any suggestions?

Michael McLoughlin
 

I have to agree with Mica - do you really need a CCMS here? We moved 18 months ago from a leading DITA CCMS because it was buggy and too expensive to Git/Github + OxygenXML and haven't looked back. We also took the opportunity to switch from unnecessary topic specialisations and remove some of the extra crud added by the CCMS. This took a little work with some bash scripts and the Oxygen XML refactor tool. It tool a month or so planning but we were able to do the entire move over a weekend. A few things we learned in the process:

1. Plan your repository architecture well in GitHub, what doc sets will live where, what branching structure you'll use, and how content can be shared between repos (we used git subtrees for that but there are other solutions such as the git subrepo tool).
2. Make sure the team are trained well on Git workflows. Tools like GitHub Desktop and the Oxygen Git plugin make that a lot easier for those team members who don't like the Git CLI commands.
3. Make sure you train your team on Oxygen. I think most people when they become confident with Oxygen never want to write DITA in anything else.
4. Take advantage of Github Actions for CI/CD stuff.

161 - 180 of 46396