Date   

Anyone Using Elasticsearch to Index DITA Content?

ekimber@contrext.com
 

In my current job role I'm contributing to an Elasticsearch-based application that is not in any way XML or DITA related. I am new to Elasticsearch but basically it uses the Apache Lucene full-text engine to index JSON data and then provide a bunch of useful search and retrieval services on top of that. It seems very cool.

However, except for the Elasticsearch Logstash tool's generic XML-to-JSON feature (designed primarily for indexing Windows XML logs I believe), there doesn't seem to be a dedicated documentation XML-to-Elasticsearch mechanism (at least I didn't find one in my initial brief searching).

But since the input to Elasticsearch is JSON there's no technical barrier to generating JSON from DITA content, but there would be some art to it.

In the DITA world we'd typically choose something like MarkLogic or XBase to do full-text searching on our content but Elasticsearch is widely used (and is open-source so it's free).

So I'm curious if anyone in the DITA community is using Elasticsearch to index their DITA content and if so, can you talk about it?

Cheers,

E.
--
Eliot Kimber
http://contrext.com


Generating header and map files in HTMLHelp

Bill Burns
 

Hello,

Developing a CHM plugin for a client. I noticed that the default CHM plugin does not generate mapping or header files from the resourceid values. Is this standard behavior, or is there some trick to getting the OT to generate these files?

Really hoping I don't have to develop that functionality myself.

Thanks,
--
Bill Burns
(737) 242-8678
--
We are [A] 


My recent e-mail

Kristen James Eberlein
 

Please ignore it; I mistakenly sent it here rather than the DITA TC, which was the intended recipient.

Best,
Kris

Kristen James Eberlein
Chair, OASIS DITA Technical Committee
OASIS Distinguished Contributor
Principal consultant, Eberlein Consulting LLC
www.eberleinconsulting.com
+1 919 622-1501; kriseberlein (skype)


Re: Chunking and topic titles

Nancy Roberts
 

I understand. Thanks for trying.

FWIW, this is the first time I've had an issue with it. But usually I only use chunking on the chapter or topic level, not on the map level.


Re: Chunking and topic titles

Michael McLoughlin
 

 I'm not familiar with Ixiasoft CCMS so I don't know if any of the stuff it adds could be to blame. Sorry I've been no help. 


Re: Chunking and topic titles

Nancy Roberts
 

Nothing suspicious that I can see. I can post the map, but without the actual titles for security reasons. 

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE bookmap PUBLIC "-//VARONIS//DTD DITA Bookmap//EN" "varonis-bookmap-drm.dtd">
<bookmap chunk="to-content" id="haa1621958012532" xml:lang="en-us"
xmlns:ditaarch="http://dita.oasis-open.org/architecture/2005/">
<booktitle ixia_locid="247">
<mainbooktitle ixia_locid="248">Doc Title</mainbooktitle>
</booktitle>
<bookmeta>
<category ixia_locid="293">activity_new<data datatype="ixia-taxonomy-term"
id="tax1537881104487:tnd1607098826062" ixia_locid="294"
value="Varonis_Taxonomy_5.2/Activity"/></category>
<category ixia_locid="295">external_child<data datatype="ixia-taxonomy-term"
id="tax1537881104487:tnd1537881104602:tnd1620084380942" ixia_locid="296"
value="Varonis_Taxonomy_5.2/External/External"/></category>
<category ixia_locid="297">External<data datatype="ixia-taxonomy-term"
id="tax1537881104487:tnd1537881104602" ixia_locid="298"
value="Varonis_Taxonomy_5.2/External"/></category>
<category ixia_locid="299">product_name<data datatype="ixia-taxonomy-term"
id="tax1537881104487:tnd16070987296911:tnd1621267227331" ixia_locid="300"
value="Varonis_Taxonomy_5.2/Product/DatAdvantage Cloud"/></category>
<category ixia_locid="301">product_new<data datatype="ixia-taxonomy-term"
id="tax1537881104487:tnd16070987296911" ixia_locid="302"
value="Varonis_Taxonomy_5.2/Product"/></category>
<category ixia_locid="303">external_integration_new<data datatype="ixia-taxonomy-term"
id="tax1537881104487:tnd1607098826062:tnd1607098840548" ixia_locid="304"
value="Varonis_Taxonomy_5.2/Activity/External Integration"/></category>
<category ixia_locid="305">product_deployment<data datatype="ixia-taxonomy-term"
id="tax1537881104487:tnd1607098826062:tnd1614633721413" ixia_locid="306"
value="Varonis_Taxonomy_5.2/Activity/Product Deployment"/></category>
</bookmeta>
<frontmatter ixia_locid="54">
 
<booklists ixia_locid="57">
<toc ixia_locid="58"/>
</booklists>
 
</frontmatter>
<chapter ixia_locid="246" keyref="rmk1537989721249" outputclass="subjectscheme"
processing-role="resource-only" scope="external"/>
<containerref href="yos1619187593532.ditamap" ixia_locid="249"/>
 
<chapter ixia_locid="290" keyref="are1621958037792">C1 - Integration Overview</chapter>
 
<chapter ixia_locid="292" keyref="qzj1621958060256">T1 - Deployment Steps</chapter>
</bookmap>


Re: Chunking and topic titles

Michael McLoughlin
 

Is there anything other than text in the T1 topic title - a conkeyref, or a maybe special character?

What output format are you using? 

Maybe you could post your map?


Re: Chunking and topic titles

Nancy Roberts
 

Hi Michael,

Yes - it didn't work.

Thanks,
Nancy


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

81 - 100 of 46324