Date   

Re: Use CMIS protocol with dita-ot #DITA-OT #CCMS #Oxygen

Radu Coravu
 

Hi Nicolas,

When you publish using the DITA OT a DITA Map which is on a remote location from Oxygen, we have some special pre-processing code which tries to download the DITA Map and its referenced topics to a local temporary files cache. So we try to make the fact that the DITA Map is remote transparent to the DITA OT. In this particular case the pre-processing code that we added to the DITA OT cannot download the remote resources probably because the credentials which you have set up in Oxygen to connect to the server are not available to the DITA OT publishing engine process.

Indeed the same thing works for Webdav resources because Oxygen passes the Webdav authentication details to the pre-processing stage we have set up in the DITA OT process. But we do not do this for any remote URL protocol connection as the authentication details are specific to each URL protocol.

It would probably be possible to make this work by making certain changes to the CMIS add-on which can be installed in Oxygen. I will add an internal issue on our side for this.

For your information the ID of the internal issue I added is:

    EXM-47697 Make DITA OT publishing work with CMIS add-on for Oxygen

Regards,

Radu

Radu Coravu
Oxygen XML Editor
On 3/26/21 10:50, Nicolas Delobel wrote:

Hello all,

My DITA files are hosted on Alfresco server (CMIS enabled server).
To modify these files I use a specific Oxygen addon based on CMIS protocol. For this part it's OK.

The problem is: when I try to launch DITA-OT publication on these files from Oxygen I have the following error:
[map-reader] 09:28:34.733 [main] ERROR ro.sync.xml.transformer.dita.remote.b - Could not download myTopic.dita because:Error opening connection: cmis://xxx.xxx.com/Sites/mySite/documentLibrary/sources/XXX/myTopic.dita
It seems that DITA-OT doesn't support CMIS protocol.

I tried to access dita files via Oxygen "Data source explorer" and it works because it use http protocol (supported by DITA-OT).

Has anyone ever faced this problem?

Thanks.
Regards,
Nicolas

  


Re: How to add multiple formats for <li> element in <ul>

Derek Fess
 

On Fri, Mar 26, 2021 at 06:39 AM, Ozana Dragomir wrote:
count(ancestor::*[contains(@class, ' topic/ul ')]) = 2
Ozana, thank you so much! That worked perfectly. I guess I didn't realize you could use the <xsl:choose> element in the attr file. I thought it was just defining each attribute set at a time.


Re: How to add multiple formats for <li> element in <ul>

Ozana Dragomir
 

Here is our code for different bullet colours:

In lists-attr.xsl

    <xsl:variable name="custom-color-purple">#72166B</xsl:variable>
    <xsl:variable name="custom-color-blue">#6687B7</xsl:variable>

    <xsl:attribute-set name="ul.li__label__content">
        <xsl:attribute name="text-align">start</xsl:attribute>
        <!-- change second level bullet color to blue and third level bullet color to purple -->
        <xsl:attribute name="color">
            <xsl:choose>
                <xsl:when test="count(ancestor::*[contains(@class, ' topic/ul ')]) = 2">
                    <xsl:value-of select="$custom-color-blue"/>
                </xsl:when>
                <xsl:when test="count(ancestor::*[contains(@class, ' topic/ul ')]) = 3">
                    <xsl:value-of select="$custom-color-purple"/>
                </xsl:when>
                <xsl:otherwise>black</xsl:otherwise>
            </xsl:choose>
        </xsl:attribute>
    </xsl:attribute-set>


I hope this helps.

Best regards,
Ozana


Re: How to add multiple formats for <li> element in <ul>

Nicolas Delobel
 

Hi Derek,

I think in you case you have to create a new a new attribute set per ul level: ul.ul.li__label, ul.ul.ul.li__label, ul.ul.ul.ul.li__label, etc.

And after, you have to apply dynamically these attibute-set based on item level using processAttrSetReflection named template:
<xsl:template match="*[contains(@class, ' topic/ul ')]/*[contains(@class, ' topic/li ')]">
        <xsl:variable name="depth" select="count(ancestor::*[contains(@class, ' topic/ul ')])"/>
        <xsl:variable name="attrName" as="xs:string">
            <xsl:for-each select="0 to $depth">ul.</xsl:for-each>
        </xsl:variable>
        <fo:list-item xsl:use-attribute-sets="ul.li">
            <xsl:call-template name="commonattributes"/>
            <fo:list-item-label>
                <xsl:call-template name="processAttrSetReflection">
                    <xsl:with-param name="attrSet" select="concat('ul',$attrName,'li__label__content')"/>
                    <xsl:with-param name="path" select="'../../cfg/fo/attrs/commons-attr.xsl'"/>
                </xsl:call-template>
                <fo:block xsl:use-attribute-sets="ul.li__label__content">
                    <xsl:call-template name="getVariable">
                        <xsl:with-param name="id" select="concat('Unordered List bullet ', (($depth - 1) mod 4) + 1)"/>
                    </xsl:call-template>
                </fo:block>
            </fo:list-item-label>
            <fo:list-item-body xsl:use-attribute-sets="ul.li__body">
                <fo:block xsl:use-attribute-sets="ul.li__content">
                    <xsl:apply-templates/>
                </fo:block>
            </fo:list-item-body>
        </fo:list-item>
    </xsl:template>
I didn't test, but I think it may work.

Regards,
Nicolas


Use CMIS protocol with dita-ot #DITA-OT #CCMS #Oxygen

Nicolas Delobel
 

Hello all,

My DITA files are hosted on Alfresco server (CMIS enabled server).
To modify these files I use a specific Oxygen addon based on CMIS protocol. For this part it's OK.

The problem is: when I try to launch DITA-OT publication on these files from Oxygen I have the following error:
[map-reader] 09:28:34.733 [main] ERROR ro.sync.xml.transformer.dita.remote.b - Could not download myTopic.dita because:Error opening connection: cmis://xxx.xxx.com/Sites/mySite/documentLibrary/sources/XXX/myTopic.dita
It seems that DITA-OT doesn't support CMIS protocol.

I tried to access dita files via Oxygen "Data source explorer" and it works because it use http protocol (supported by DITA-OT).

Has anyone ever faced this problem?

Thanks.
Regards,
Nicolas


How to add multiple formats for <li> element in <ul>

Derek Fess
 

I'm running DITA-OT 3.2.1

Our company has rebranded, and as such we now have a new Marketing style guide. I need to format three levels of bullets. This part I've done (using the commonvariables.xml file). However, I need to make them different colors depending on which level they are at. All that I can seem to do is set the color for all levels, using the ul.li__label attribute set. If I understand correctly, I can make a new attribute set (say ul.li.li__label), but would have to call it from the lists.xsl file. This is where I am stuck. I do not know xslt well enough to know how to construct what I need. I know I need to use this piece of code from the pdf2 lists.xsl file:

<xsl:template match="*[contains(@class, ' topic/ul ')]/*[contains(@class, ' topic/li ')]">
        <xsl:variable name="depth" select="count(ancestor::*[contains(@class, ' topic/ul ')])"/>
        <fo:list-item xsl:use-attribute-sets="ul.li">
            <xsl:call-template name="commonattributes"/>
            <fo:list-item-label xsl:use-attribute-sets="ul.li__label">
                <fo:block xsl:use-attribute-sets="ul.li__label__content">
                    <xsl:call-template name="getVariable">
                        <xsl:with-param name="id" select="concat('Unordered List bullet ', (($depth - 1) mod 4) + 1)"/>
                    </xsl:call-template>
                </fo:block>
            </fo:list-item-label>
            <fo:list-item-body xsl:use-attribute-sets="ul.li__body">
                <fo:block xsl:use-attribute-sets="ul.li__content">
                    <xsl:apply-templates/>
                </fo:block>
            </fo:list-item-body>
        </fo:list-item>
    </xsl:template>

Any help would be greatly appreciated.


Re: Group reltable Links by Topic Type #reltable

@l3arn4life
 

Good morning Radu (and everyone else, of course),

after researching the topic all morning I still don’t have the first clue how to implement your suggestion. Would you mind giving me some hints or pointing me to a resource for dummies that explains how one would go about overriding templates using XSLT extension points?
Thank you kindly.

Regards,
Ed


[Ann] Oxygen Git Client add-on version 2.5.0 is now released! #Oxygen

alin_belu@...
 

Hello,

We are excited to announce the release of the Oxygen Git Client add-on version 2.5.0!

This add-on is compatible with Oxygen XML Editor/Author/Developer version 21.1 or higher.

Some of the most important features found in the newest version of the add-on were also some of the most requested, such as the improvements made for when working with submodules:
* After a repository that contains submodules is cloned, all submodules are also automatically initialized and cloned.
* When pulling the remote changes for a repository that contains submodules, the submodules are updated as well (by default). This behavior depends on the Update all submodules after pulling changes from the remote repository option from the Git Client preferences page in Oxygen.
* If a submodule appears as changed in the Unstaged files area, you can open it using the Open action from the contextual menu.
* The tooltip shown for a modified submodule from the Unstaged files area now presents information about the currently and previously tracked commits.

Other improvements added in version 2.5.0 of the Oxygen Git Client add-on that expand its functionality even further include:
* The addition of a new field in the login dialog box for authentication using a personal access token. Note that from August 13, 2021, GitHub will no longer accept password-based authentication (https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations).
* Branches created from other local branches are now automatically checked out. This behavior can be disabled by deselecting the Checkout branch option in the Create branch dialog box.
* The Git Staging side-view has been slightly redesigned and now has a cleaner look.
* Added support for Dutch localization.
* Fixed an issue where debugging the Git Client using Apache Log4j did not work.
* Fixed an issue where opening submodules that required authentication was not possible.
* Fixed various other bugs and added several small UX improvements.

Also, make sure to check the README page for the Git Client add-on on GitHub:
https://github.com/oxygenxml/oxygen-git-plugin/blob/master/README.md

We hope that you will enjoy using the latest release of the Oxygen Git Client add-on as much as we enjoyed developing it!

Best regards,
Alin

--
Alin Belu
Oxygen XML Editor


Re: DITA and static site generators

despopoulos_chriss
 

The approach we took is to transform DITA to HTML in the browser.  This satisfies Docs as Code, in that a build simply takes our DITA source and places it on the server as is.  On the server side it's totally static.  But on the client side it's dynamic.  We use real-time filtering of the source to implement micro-content, for example.  Lots of metadata in a topic, and selective display at request time. 

I'll give a talk on how we do micro-content at the upcoming ConVex (replacement for DITA N. America and DITA Europe). 

We use a minimal subset of DITA -- Only use Topic, don't do specialization, and we don't support some of the more arcane features.  (We do support conrefs and keyrefs, though.)  We put this together about 8 years ago, when LwDITA was roughly a twinkle in Michael Priestly's eye, so we just did our own subset. 

The one thing we cannot do is directly port over to GitHub Pages.  GHP doesn't support AJAX, and we use AJAX to get the topic and the transform.  I finally need to figure out a workflow between GHP and our system, so we'll see how that goes.

FWIW...      cud


Re: DITA and static site generators

Mark Giffin
 

Michael, thanks for the info on trying to use MDITA with various static site generators. I'm on the Lightweight DITA subcommittee and it's good to hear how people are trying to use it.

I haven't used the markdown_github DITA OT transtype much. The docs for it say it converts DITA files to GitHub-Flavored Markdown, which does not have YAML headers. This is equivalent to "core profile" MDITA. Probably the markdown_github plugin could be modified to output something like "extended profile" MDITA, which does allow YAML headers.

I can also imagine a fairly simple DITA OT plugin that would convert MDITA markdown into a markdown flavor that is compatible with a given static site generator. So if you want it to just pass through HTML tables embedded in the markdown, you could do it.

There is no markdown flavor that will work with all or even most static site generators, that I know of. Since there is no real standard for markdown, your static site generator (if you use one) tends to be the validator for your flavor's syntax. Unless you have an editor that will do it. Oxygen has something like this for MDITA.

I've used the Lightweight DITA markdown flavor (MDITA) for a couple clients over the last couple of years and it has worked pretty well for them as it is right now. They are mainly using it as an easier authoring format. It fits in well with an existing DITA setup where some people are using full XML DITA and others want something simple. You can put XML and mdita topic files in the same map. It's easy to publish the markdown/mdita and have it fit in with the existing DITA publishing. I have found that late-model versions of the DITA Open Toolkit handle it pretty well for my purposes.

I hear that Adobe has been using MDITA internally in some places for a while. There are others also. This is using the current Lightweight DITA Committee Note, which is not the finished specification.

http://docs.oasis-open.org/dita/LwDITA/v1.0/cn01/LwDITA-v1.0-cn01.html

Regards,
Mark Giffin
Mark Giffin Consulting, Inc.



On 3/20/2021 4:46 AM, Michael McLoughlin wrote:
Hi Mark,
             Principally the lack of YAML headers. I have noticed too that the markdown_github transform changes HTML tables into PHP Extra format tables - and not very well. Not sure why they cannot just be left in HTML.
I think LwDITA has a ways to go before it is enterprise ready. Not sure how much it will change now before its release. I had an exchange recently with  Michael Priestley on LinkedIn and he reckons it'll be early 2022 before it comes out.

I think the improvements it needs will only really come about once it is let loose in the real world and people start developing more plugins and the tools folks like Oxygen and Adobe start really getting involved.


Re: DITA and static site generators

Michael McLoughlin
 

Hi Mark,
             Principally the lack of YAML headers. I have noticed too that the markdown_github transform changes HTML tables into PHP Extra format tables - and not very well. Not sure why they cannot just be left in HTML.
I think LwDITA has a ways to go before it is enterprise ready. Not sure how much it will change now before its release. I had an exchange recently with  Michael Priestley on LinkedIn and he reckons it'll be early 2022 before it comes out.

I think the improvements it needs will only really come about once it is let loose in the real world and people start developing more plugins and the tools folks like Oxygen and Adobe start really getting involved.


Re: DITA and static site generators

Mark Giffin
 

Hi Michael,

What is missing for you to be able to use MDITA with Jekyll, Hugo, Docusaurus? Is it just the YAML header or other things?

I've converted between different flavors of markdown (there are lots of them), and often things like tables are also different.

Regards,
Mark Giffin
Mark Giffin Consulting, Inc.

On 3/19/2021 6:59 AM, Michael McLoughlin wrote:

That's really interesting, Wayne.

How are you handling things like keys and conrefs? 

What drew me to trying MDITA was that I could include keys, conrefs and filters directly into the Markdown (with a little HTML5). Admittedly, the tool support is not there yet for LwDITA and I'd really love someone to do a transform plugin that preserved the extended MDITA YAML header in the Markdown so they files could be plugged into Jekyll or Hugo or Docusaurus. Unfortunately I don't have the Java chops to write one myself.

I think being able to plugin DITA directly into static site generator would be a great advantage as an alternative to styling the HTML5 plugin or even the Oxygen Webhelp plugin.



Re: DITA and static site generators

Michael McLoughlin
 

On Fri, Mar 19, 2021 at 02:42 PM, Wayne Brissette wrote:
If we ever get back to doing DITA North America presentations, I might consider doing a session on what we did and how it's working out.

You should. I'd be up to see that. 

I think there are lot of us trying to find out a way with DITA on GitHub and getting it work in a docs-as-code workflow. I think your solution would certainly solicit interest.


Re: DITA and static site generators

Michael McLoughlin
 

On Fri, Mar 19, 2021 at 03:09 PM, Mica Semrick wrote:
You should have a look at the dita-ot.org website on github. Roger has done exactly this, he mixes dita output with markdown content and publishes using a static site generator.

Excellent idea. I'll see what I can steal. Isn't open source a wonderful thing!


Re: DITA and static site generators

Mica Semrick
 

You should have a look at the dita-ot.org website on github. Roger has done exactly this, he mixes dita output with markdown content and publishes using a static site generator.


On March 19, 2021 2:41:28 AM PDT, michael.mcloughlin@... wrote:

I was wondering if anyone is using DITA markdown output with a static site generator and what your experience is.

I've been playing with the MDITA flavor of LWDITA and outputting it to standard markdown. There exists markdown transforms to output to Gitbook/MdBook and even MKDocs. I've got content building nicely in Docsify too with the markdown_github output from the LwDITA plugin.

Is anyone automating DITA-OT builds to add markdown output to other static site generators like Jekyll, Hugo, Docusaurus, Gatsby etc.?


Re: DITA and static site generators

Wayne Brissette
 

Michael McLoughlin wrote on 2021-03-19 08:59:

That's really interesting, Wayne.

How are you handling things like keys and conrefs?
We don't they are writing in pure MD. We have constrained our DTDs and so we have content models they have to use. If their MD doesn't conform, it won't build and they get an error. Actually more times than not, my script fails telling them what it couldn't do or find. At that point it's up to engineering and the information developer to work out how to resolve it. Usually it's a formatting issue.

CommonMark/Markdown was always designed for lightweight authoring. I consider anything like keys and conrefs to be a bit heavier than we want to handle in MD, so if that's the requirement, I punt them to our DITA system. That said, I have built in a system whereby they can use custom variables and their is no limitation on that that looks like, so I've seen where product names, and indeed entire sentences are swapped out before the DITA is written.

I did the work in Python, although to be honest, I would have preferred to do this in Ruby because the Nokogiri XML library is better than LXML, but since I'm one of the few folks on my team that has any real experience with Ruby, we went with Python since that's the 'flavor of the day' and all of our new college grads we are bringing in understand it and can write it.

If we ever get back to doing DITA North America presentations, I might consider doing a session on what we did and how it's working out.

-Wayne


[ann] Version 1.1.0 of the Oxygen DITA Prolog Updater add-on is now available! #Oxygen

alin_belu@...
 

Hello,  
 
We are excited to announce that version 1.1.0 of the Oxygen DITA Prolog Updater add-on is now available in the Oxygen XML default add-on repository!   
 
Version 1.1.0 of the Oxygen DITA Prolog Updater add-on comes with these useful new improvements:  
* The possibility to customize the value of the type attribute for the author element that is inserted to allow you to specify the primary (creator) author. 
* A new option was added that lets you customize the value of the type attribute for the author element that is inserted to allow you to specify an additional author (contributor). 
* The process was improved so that an additional author (contributor) cannot be added if they are already specified as the primary (creator) author. 
* An issue where a warning message was reported even though prolog updating was disabled has been fixed. 
 
To install the add-on, follow these instructions:   
1. In Oxygen, 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 DITA Prolog Updater 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. 
 
For more information, see the details for the Oxygen DITA Prolog Updater add-on on GitHub:   
 
We hope you will find this add-on useful and, as always, your feedback is welcomed!   
 
Best regards,
Alin  

--
Alin Belu
Oxygen XML Editor


Re: DITA and static site generators

Michael McLoughlin
 

That's really interesting, Wayne.

How are you handling things like keys and conrefs? 

What drew me to trying MDITA was that I could include keys, conrefs and filters directly into the Markdown (with a little HTML5). Admittedly, the tool support is not there yet for LwDITA and I'd really love someone to do a transform plugin that preserved the extended MDITA YAML header in the Markdown so they files could be plugged into Jekyll or Hugo or Docusaurus. Unfortunately I don't have the Java chops to write one myself.

I think being able to plugin DITA directly into static site generator would be a great advantage as an alternative to styling the HTML5 plugin or even the Oxygen Webhelp plugin.


Re: too big bother

Aaron Mehl
 

Thanks, 
That's exactly what I needed. I should have guessed that keyref could go in uicontrol, etc. but I just learned something new. I guess I will indeed need a separate map for my keydef's....
In fact I will have to reorganize my maps altogether. There is so much to learn....
Thanks,
Aaron

On Wednesday, March 17, 2021, 03:41:09 PM EDT, Chris Brand via groups.io <chrizzbee74@...> wrote:


Sorry, you asked for code view. Here you go.

Map with all UI keys:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE map PUBLIC "-//XPLM//DTD DITA Map//EN" "map.dtd">
<map>
...
?????? <topicgroup>
?????????? <topicmeta>
?????????????? <navtitle>field</navtitle>
?????????? </topicmeta>
?????????? <keydef keys="new_f_name">
?????????????? <topicmeta>
?????????????????? <keywords>
?????????????????????? <keyword>Name</keyword>
?????????????????? </keywords>
?????????????? </topicmeta>
?????????? </keydef>
?????????? <keydef keys="new_f_targetDir">
?????????????? <topicmeta>
?????????????????? <keywords>
?????????????????????? <keyword>Target directory</keyword>
?????????????????? </keywords>
?????????????? </topicmeta>
?????????? </keydef>
?????? </topicgroup>
...
</map>

Concept topic:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE concept PUBLIC "-//XPLM//DTD DITA Concept//EN" "concept.dtd">
<concept id="concept_jjh_vrd_n1b" xml:lang="en">
?????? ...
?????? <section>
?????????? <title>Section: <ph keyref="new_s_settings"/></title>
?????????? <p>In this section, you can define the project name and the project directory.</p>
?????????? <p>
?????????????? <table frame="all" rowsep="1" colsep="1">
?????????????????? <tgroup cols="2">
?????????????????????? <colspec colname="c1" colnum="1" colwidth="2*"/>
?????????????????????? <colspec colname="c2" colnum="2" colwidth="5*"/>
?????????????????????? <thead>
?????????????????????????? <row>
?????????????????????????????? <entry>Label</entry>
?????????????????????????????? <entry>Description</entry>
?????????????????????????? </row>
?????????????????????? </thead>
?????????????????????? <tbody>
?????????????????????????? <row>
?????????????????????????????? <entry><uicontrol keyref="open_f_name"/> (F)</entry>
?????????????????????????????? <entry>Defines the project name.</entry>
?????????????????????????? </row>
?????????????????????????? <row>
?????????????????????????????? <entry><uicontrol keyref="new_f_targetDir"/> (F)</entry>
?????????????????????????????? <entry>Defines the directory where the design data will be created.</entry>
?????????????????????????? </row>
?????????????????????????? <row>
?????????????????????????????? <entry><b>Browse</b> (B)</entry>
?????????????????????????????? <entry>Opens Windows Explorer to select a directory.</entry>
?????????????????????????? </row>
?????????????????????? </tbody>
?????????????????? </tgroup>
?????????????? </table>
?????????? </p>
?????? </section>
?????? ...
</concept

Good luck!

Greez,
Chris.



Am 17.03.21 um 16:16 schrieb Aaron Mehl via groups.io:

Thanks, I saw this same issue on a old webinar but didn't get it then. I will print out your screen capture and spend some time on this.??

These aspects of Dita deserve my attention, wow,
Thanks,
Aaron
On Wednesday, March 17, 2021, 06:14:20 AM EDT, Chris Brand via groups.io <chrizzbee74@...> wrote:


Hi Aaron

I keep key definitions in a separate map and use topic-group elements to structure it. I then can search for the key in the "DITA Reusable Components" view and insert it (often as <uicontrol>).
See screenshot below for an example.



Greez,
Chris.


Re: DITA and static site generators

Wayne Brissette
 

michael.mcloughlin@puppet.com wrote on 2021-03-19 04:41:

Is anyone automating DITA-OT builds to add markdown output to other static site generators like Jekyll, Hugo, Docusaurus, Gatsby etc.?
We're going the other way... that is, we have built a pipeline that allows engineering to work more collaboratively with our information developers but using a combination of git, jenkins and markdown. We take the markdown, along with a YAML file with the metadata in it, and then using a custom script I wrote, generates fully fleshed out DITA. We automate the OT at this stage, but if for any reason we need to put this content into our CCMS, we have fully qualified DITA. We tried LWDITA, but we weren't happy with the results, so we built our own pipeline and processing. The nice thing is now our IDs are really collaborating for the first time with engineering at the design stage. We're still at the early stages of deployment, but for some teams this flow works. For others, the full DITA workflow still works better.

We have thought about generating CommonMark as one of outputs, but thus far, there hasn't been a pressing need. But for us I could see a need if one of our more traditional DITA teams needed to move content the other direction. However, I've not had the time to do much investigation into what this would really look like.

-Wayne

121 - 140 of 46224