Date   

Re: New Oxygen add-on to help translators

Jonathan Hanna
 

Hi Radu,

Thank you for bringing this great feature to our attention! I just tried using it and was able to get it to work when selecting all the content in a topic or all the content in a section. However, the Translation using Google Translate dialog does not show up when I select only a single block of text (such as all the text in a <p> element). Is that the intended behavior or is there a bug?

Regards,
Jonathan


Re: Are you using <data-about>?

glenn emerson
 

I’ve never used it either, though I have used <data> quite a bit.

On Sep 1, 2020, at 5:02 PM, ekimber@contrext.com wrote:

I have never used data-about, even when I thought it would be a useful thing to do.

Basically, the authoring overhead required to make the authoring of data-about practical coupled with the need to implement whatever data-about processing you might need means that the implementation cost almost (or always) outweighs any potential value from a metadata representation standpoint.

In addition, because the TC has expanded the places where <data> is allowed, it's largely removed the need to be able to point at something within a topic or map in order to impose metadata on to it (the intended purpose of data-about).

I can imagine some use case where you might want to use DITA to impose metadata onto non-DITA objects but doing so with DITA and data-about would be so one-off and outside the mainstream of any existing metadata infrastructure that I can't see it ever being done. And even without data-about you can get the same effect with topicrefs that contain the metadata they want to impose (which is basically what subject scheme does).

I think data-about falls into the category of DITA features that were a good idea at the time or were suggested by design symmetry and completeness but where overtaken by practical realities and other technologies.

Cheers,

E.

--
Eliot Kimber
http://contrext.com


On 9/1/20, 4:24 PM, "Kristen James Eberlein" <main@dita-users.groups.io on behalf of kris@eberleinconsulting.com> wrote:







At today's DITA Technical Committee meeting, we discussed the
possibility of removing <data-about> from DITA 2.0. The
rationale for removal is:


* The spec element-reference topic is extremely convoluted.
Neither spec editors (Robert Anderson and I) has been able to
rework it and make it comprehensible.

* There is nothing done with <data-about> that cannot be
done with <data>.

* We suspect that the element is little used -- and if used, is
usually misused.


So, our query to the larger DITA-using community:


* Does your implementation use the <data-about> element?

* (If the <data-about> element is used) What are the use
cases for <data-about>? Please note that these should be
actual, not theoretical.


As always, thanks for your participation in the dita-users list.

--
Best,
Kris

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











relationship beteween 3 types of documents for the same concept

Weiwu Zhang
 

We have a tech called TokenScript which has concepts that is

- Defined in XML by Token Issuers
- Presented to the web developers as JavaScript

For example, a concept called Card will have 3 pages of document

𝑎. What is a Card, where to use it

𝑏. How is it defined in XML (interesting to the XML author)

𝑐. How is it used by JavaScript web developers (interesting to the web
developer who takes the XML and use it as a library)

All of the three are about the same thing, but each of them is
included in a different dita map.

My question is what's the best practise to connect these 3 types of
document?

Right now,

𝑎 is in a concept called Card.dita
𝑏 is in a topic called card_element.dita
𝑐 is in a topic called manipulate_card_in_JavaScript.dita

They are connected in a rudimentary way: in 𝑎, there are two <note>
elements that links to the corrisponding document 𝑏 and 𝑐; and there
are <notes> in 𝑏 and 𝑐 linking back to 𝑎.

With a bit of Google search I found the <audience> tag which is
relevant, but it seem to be a way to tag information by audience,
doesn't work to linking documents of one same concept for different
audiences.

These days I always got the right answers from this mailing list so thanks
in advance!

P.S. I feel DITA itself need such kind of "linking mechanism". Sometimes,
in the Style Guide I found a dita document page about where to use it,
then I need to do a second Google search to find out how to use it.
Maybe there are mechanism to do so, but can't be used because Style
Guide is from different DITA repository than the how-to information.

Regards
Weiwu Z.


Re: Can LwDITA MDITA format transclude "normal" dita content?

Weiwu Zhang
 

On Mon, 31 Aug 2020, Radu Coravu wrote:

If you open it in a DITA editing tool and validate it, there are about 4
problems with it:
1) The element <div> is not accepted in a Lightweight DITA topic. Only the
following elements are allowed:
2) The @conref element is allowed only on these Lightweight DITA elements:
3) The @type element is not allowed on the <div> element.
4) When you conref in a DITA topic you need to conref to an equivalent DITA
element from the target topic. So a DITA <div> may conref to another <div>
located in another DITA topic, not to a <concept> element.
Thanks Radu. Having fixed all 4 problems now the document works!

changing the element to <section>, now conref from a <section> to a <section> and dropped @type (as referring to XDITA doesn't require specifying type).

Regards
Weiwu Z.


New Oxygen add-on to help translators

Radu Coravu
 

Hi everyone,

Over the course of this summer one of our interns, Mircea Badoi, worked on a free Oxygen XML add-on designed to help translating XML content.

Starting from yesterday, the add-on is available for Oxygen vesions 21.1 or newer in our default add-on repository. If you want to install it, you can use the Oxygen main menu "Help->Install new add-ons", choose the default Oxygen add-on update site and you will find an add-on named "Translator Helper (Experimental)" in the list.

The add-on has two main features:

  1. You can translate content using Google Translate to various languages:
    • Select the content to translate in the Author visual editing mode. You can also select the entire document contents. DITA topics are small so you can select the entire topic contents.
    • Right click. Select "Google Translate into" and choose the target language.
    • Copy the translated content from the opened web page.
    • Click Replace in the Oxygen Translate using Google Translate dialog that showed up. The original content should now be replaced with the translated content, the original element structure and attributes should remain unchanged.
    • In addition you can choose to show the original document content in the Translator Helper side view. This will allow you to correct the translation further by looking at the original text and the translated text side by side.
  2. You can see the original content side by side with the content that you are translating, so you can translate correctly and easy by right clicking in the Author visual editing mode and invoking the Show current content in side view action.

So I hope you will enjoy the add-on, if you have questions or improvement requests, they are as usual welcomed. One area in which the plugin may be useful is for example if you want to quickly demo to a customer how a topic written in English would look like in other languages like Japanese Chinese, French, German, Russian, etc.

Regards,

Radu

Radu Coravu
Oxygen XML Editor


Re: error in producing troff output

Radu Coravu
 

Hi,

I had the changes to make the plugin work on my side, as part of the DITA Open Toolkit bundled with Oxygen XML Editor, so I just added them back to the original project.

About the issue you added, I'm not very familiar with troff output but maybe someone else will be able to help. Maybe as a workaround for the problem instead of a DITA <section> you could insert another <concept> element after the end of the </conbody> in the first concept.

Regards,
Radu

Radu Coravu
Oxygen XML Editor

On 9/3/20 3:16 AM, Weiwu Zhang wrote:


On Wed, 2 Sep 2020, Radu Coravu wrote:

I added an issue on the plugin's GitHub issues list to make it compatible
with DITA OT 3.5:

https://github.com/dita-ot/org.dita.troff/issues/5
Impressive! The issue is solved in 24 hours.

Following what you did I filed another issue about a bug in the troff output that concatenated two unrelated paragraphs. Hope that the project responds.


Re: error in producing troff output

Weiwu Zhang
 

On Wed, 2 Sep 2020, Radu Coravu wrote:

I added an issue on the plugin's GitHub issues list to make it compatible
with DITA OT 3.5:
https://github.com/dita-ot/org.dita.troff/issues/5
Impressive! The issue is solved in 24 hours.

Following what you did I filed another issue about a bug in the troff output that concatenated two unrelated paragraphs. Hope that the project responds.


Re: proper way to do trouble-shooting containing console commands

Weiwu Zhang
 

On Wed, 2 Sep 2020, danlittman via groups.io wrote:

Weiwu, just want to point out before you release this error message
that the <p> </p> says singing, instead of signing. _._,_._,_
Weiwu here. Thank you! And thank you everyone who proposed the new
element.


Re: proper way to do trouble-shooting containing console commands

danlittman
 

On Tue, Sep 1, 2020 at 03:35 AM, Weiwu Zhang wrote:
<condition>
<title>Wrong key used for signing</title>
<p>Error on the singing</p>
</condition>
Weiwu, just want to point out before you release this error message that the <p> </p> says singing, instead of signing.


Re: error in producing troff output

Radu Coravu
 

Hi,

The readme for the DITA to Troff plugin says:

https://github.com/dita-ot/org.dita.troff

Compatibility

  • DITA-OT 3.1
So it no longer works with DITA OT 3.5.x. Maybe you can download an older version of the DITA OT publishing engine (3.1) and try to use this plugin with it.

I added an issue on the plugin's GitHub issues list to make it compatible with DITA OT 3.5:

https://github.com/dita-ot/org.dita.troff/issues/5

Regards,
Radu
Radu Coravu
Oxygen XML Editor
On 9/1/20 4:30 PM, Weiwu Zhang wrote:
Following the guide from here:

https://www.dita-ot.org/plugins#!org.dita.troff

I installed the plugin on dita-ot 3.6

$ dita install org.dita.troff
Added org.dita.troff

and attempted to make troff out of a file:

$ dita --input=a_topic.dita --format=troff
Error: Includesfile /tmp/temp20200901230030922/${fullditatopicfile} not found.

No luck replacing the dita file with a ditamap either. It is from a project which already works with other output (html5/pdf).

Any hint how to proceed on / file bug?

Regards







  


Re: Are you using <data-about>?

ekimber@contrext.com
 

I have never used data-about, even when I thought it would be a useful thing to do.

Basically, the authoring overhead required to make the authoring of data-about practical coupled with the need to implement whatever data-about processing you might need means that the implementation cost almost (or always) outweighs any potential value from a metadata representation standpoint.

In addition, because the TC has expanded the places where <data> is allowed, it's largely removed the need to be able to point at something within a topic or map in order to impose metadata on to it (the intended purpose of data-about).

I can imagine some use case where you might want to use DITA to impose metadata onto non-DITA objects but doing so with DITA and data-about would be so one-off and outside the mainstream of any existing metadata infrastructure that I can't see it ever being done. And even without data-about you can get the same effect with topicrefs that contain the metadata they want to impose (which is basically what subject scheme does).

I think data-about falls into the category of DITA features that were a good idea at the time or were suggested by design symmetry and completeness but where overtaken by practical realities and other technologies.

Cheers,

E.

--
Eliot Kimber
http://contrext.com


On 9/1/20, 4:24 PM, "Kristen James Eberlein" <main@dita-users.groups.io on behalf of kris@eberleinconsulting.com> wrote:







At today's DITA Technical Committee meeting, we discussed the
possibility of removing <data-about> from DITA 2.0. The
rationale for removal is:


* The spec element-reference topic is extremely convoluted.
Neither spec editors (Robert Anderson and I) has been able to
rework it and make it comprehensible.

* There is nothing done with <data-about> that cannot be
done with <data>.

* We suspect that the element is little used -- and if used, is
usually misused.


So, our query to the larger DITA-using community:


* Does your implementation use the <data-about> element?

* (If the <data-about> element is used) What are the use
cases for <data-about>? Please note that these should be
actual, not theoretical.


As always, thanks for your participation in the dita-users list.

--
Best,
Kris

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


Re: Are you using <data-about>?

Lionel Moizeau
 

Hi 
I do not, I was actually wondering what it was for...

Lionel Moizeau

On Tue, Sep 1, 2020 at 11:24 PM Kristen James Eberlein <kris@...> wrote:

At today's DITA Technical Committee meeting, we discussed the possibility of removing <data-about> from DITA 2.0. The rationale for removal is:

  • The spec element-reference topic is extremely convoluted. Neither spec editors (Robert Anderson and I) has been able to rework it and make it comprehensible.
  • There is nothing done with <data-about> that cannot be done with <data>.
  • We suspect that the element is little used -- and if used, is usually misused.

So, our query to the larger DITA-using community:

  • Does your implementation use the <data-about> element?
  • (If the <data-about> element is used) What are the use cases for <data-about>? Please note that these should be actual, not theoretical.

As always, thanks for your participation in the dita-users list.

--
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)


Are you using <data-about>?

Kristen James Eberlein
 

At today's DITA Technical Committee meeting, we discussed the possibility of removing <data-about> from DITA 2.0. The rationale for removal is:

  • The spec element-reference topic is extremely convoluted. Neither spec editors (Robert Anderson and I) has been able to rework it and make it comprehensible.
  • There is nothing done with <data-about> that cannot be done with <data>.
  • We suspect that the element is little used -- and if used, is usually misused.

So, our query to the larger DITA-using community:

  • Does your implementation use the <data-about> element?
  • (If the <data-about> element is used) What are the use cases for <data-about>? Please note that these should be actual, not theoretical.

As always, thanks for your participation in the dita-users list.

--
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: proper way to do trouble-shooting containing console commands

 

Tag anything that a user types with <userinput>.  
Grant

On Tue, Sep 1, 2020 at 4:36 AM Weiwu Zhang via groups.io <weiwu.zhang=alphawallet.com@groups.io> wrote:

Hi just made my first troubleshoot guide that instructs the user to type a
few commands to find the problem.

I've got a dilemma here:

- if I put the command-to-type in <cmdname> I feel wrong because <cmdname>
is for the name of the command, not the full command.

- if I put the command-to-type inside the <codeblock> I feel wrong too
since that is included in the <stepresult> but it's not part of the
result.

What would you normally do?

Thanks!

--

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE troubleshooting PUBLIC "-//OASIS//DTD DITA Troubleshooting//EN" "troubleshooting.dtd">
<troubleshooting id="troubleshooting_signing">
     <title>Troubleshooting Signing</title>
     <troublebody>
         <condition>
             <title>Wrong key used for signing</title>
             <p>Error on the singing</p>
         </condition>
         <troubleSolution>
             <cause>
                 <title>Cause</title>
                 <p>The signing key doesn't match the certificate.</p>
             </cause>
             <remedy>
                 <title>Remedy</title>
                 <responsibleParty>Token Issuer</responsibleParty>
                 <steps>
                     <step>
                         <cmd>Use <cmdname>openssl ec -in key -pubout</cmdname> command (replace
                                 <codeph>key</codeph> with your actual key file) to generate the
                             public key from the private key. Run the following command:</cmd>
                         <stepresult>
                             <codeblock>read EC key
writing EC key
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEwXfiK2ao/T8EDv02rr1a0xZYKkox
v3FGDltKFLsZNIyTUo5RAhFh8RXy8/hqSlozGfd3pOx/70LeGzbWd/ExQg==
-----END PUBLIC KEY-----</codeblock>
                         </stepresult>
                     </step>

                     <step>
                         <cmd>Use <cmdname>openssl x509 -pubkey -in crt</cmdname> command (replace
                                 <codeph>crt</codeph> with your actual certificate file) to show the
                             public key in the certificate's subject:</cmd>
                         <stepresult>
                             <codeblock>$
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEwXfiK2ao/T8EDv02rr1a0xZYKkox
v3FGDltKFLsZNIyTUo5RAhFh8RXy8/hqSlozGfd3pOx/70LeGzbWd/ExQg==
-----END PUBLIC KEY-----</codeblock>
                         </stepresult>
                     </step>
                     <step>
                         <cmd>Check if the public key generated from the private key is the same as
                             the public key in the certificate's subject. If they are not the same,
                             your key doesn't match your certificate. Try to obtain the right key /
                             certificate.</cmd>
                     </step>
                 </steps>
             </remedy>
         </troubleSolution>
     </troublebody>
</troubleshooting>




error in producing troff output

Weiwu Zhang
 

Following the guide from here:

https://www.dita-ot.org/plugins#!org.dita.troff

I installed the plugin on dita-ot 3.6

$ dita install org.dita.troff
Added org.dita.troff

and attempted to make troff out of a file:

$ dita --input=a_topic.dita --format=troff
Error: Includesfile /tmp/temp20200901230030922/${fullditatopicfile} not found.

No luck replacing the dita file with a ditamap either. It is from a project which already works with other output (html5/pdf).

Any hint how to proceed on / file bug?

Regards


Re: proper way to do trouble-shooting containing console commands

Kristen James Eberlein
 

Use <userinput> for a command that the user should type.

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)

On 9/1/2020 6:35 AM, Weiwu Zhang via groups.io wrote:

Hi just made my first troubleshoot guide that instructs the user to type a few commands to find the problem.

I've got a dilemma here:

- if I put the command-to-type in <cmdname> I feel wrong because <cmdname> is for the name of the command, not the full command.

- if I put the command-to-type inside the <codeblock> I feel wrong too since that is included in the <stepresult> but it's not part of the result.

What would you normally do?

Thanks!

--

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE troubleshooting PUBLIC "-//OASIS//DTD DITA Troubleshooting//EN" "troubleshooting.dtd">
<troubleshooting id="troubleshooting_signing">
    <title>Troubleshooting Signing</title>
    <troublebody>
        <condition>
            <title>Wrong key used for signing</title>
            <p>Error on the singing</p>
        </condition>
        <troubleSolution>
            <cause>
                <title>Cause</title>
                <p>The signing key doesn't match the certificate.</p>
            </cause>
            <remedy>
                <title>Remedy</title>
                <responsibleParty>Token Issuer</responsibleParty>
                <steps>
                    <step>
                        <cmd>Use <cmdname>openssl ec -in key -pubout</cmdname> command (replace
                                <codeph>key</codeph> with your actual key file) to generate the
                            public key from the private key. Run the following command:</cmd>
                        <stepresult>
                            <codeblock>read EC key
writing EC key
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEwXfiK2ao/T8EDv02rr1a0xZYKkox
v3FGDltKFLsZNIyTUo5RAhFh8RXy8/hqSlozGfd3pOx/70LeGzbWd/ExQg==
-----END PUBLIC KEY-----</codeblock>
                        </stepresult>
                    </step>

                    <step>
                        <cmd>Use <cmdname>openssl x509 -pubkey -in crt</cmdname> command (replace
                                <codeph>crt</codeph> with your actual certificate file) to show the
                            public key in the certificate's subject:</cmd>
                        <stepresult>
                            <codeblock>$ -----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEwXfiK2ao/T8EDv02rr1a0xZYKkox
v3FGDltKFLsZNIyTUo5RAhFh8RXy8/hqSlozGfd3pOx/70LeGzbWd/ExQg==
-----END PUBLIC KEY-----</codeblock>
                        </stepresult>
                    </step>
                    <step>
                        <cmd>Check if the public key generated from the private key is the same as
                            the public key in the certificate's subject. If they are not the same,
                            your key doesn't match your certificate. Try to obtain the right key /
                            certificate.</cmd>
                    </step>
                </steps>
            </remedy>
        </troubleSolution>
    </troublebody>
</troubleshooting>




proper way to do trouble-shooting containing console commands

Weiwu Zhang <weiwu.zhang@...>
 

Hi just made my first troubleshoot guide that instructs the user to type a few commands to find the problem.

I've got a dilemma here:

- if I put the command-to-type in <cmdname> I feel wrong because <cmdname> is for the name of the command, not the full command.

- if I put the command-to-type inside the <codeblock> I feel wrong too since that is included in the <stepresult> but it's not part of the result.

What would you normally do?

Thanks!

--

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE troubleshooting PUBLIC "-//OASIS//DTD DITA Troubleshooting//EN" "troubleshooting.dtd">
<troubleshooting id="troubleshooting_signing">
<title>Troubleshooting Signing</title>
<troublebody>
<condition>
<title>Wrong key used for signing</title>
<p>Error on the singing</p>
</condition>
<troubleSolution>
<cause>
<title>Cause</title>
<p>The signing key doesn't match the certificate.</p>
</cause>
<remedy>
<title>Remedy</title>
<responsibleParty>Token Issuer</responsibleParty>
<steps>
<step>
<cmd>Use <cmdname>openssl ec -in key -pubout</cmdname> command (replace
<codeph>key</codeph> with your actual key file) to generate the
public key from the private key. Run the following command:</cmd>
<stepresult>
<codeblock>read EC key
writing EC key
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEwXfiK2ao/T8EDv02rr1a0xZYKkox
v3FGDltKFLsZNIyTUo5RAhFh8RXy8/hqSlozGfd3pOx/70LeGzbWd/ExQg==
-----END PUBLIC KEY-----</codeblock>
</stepresult>
</step>

<step>
<cmd>Use <cmdname>openssl x509 -pubkey -in crt</cmdname> command (replace
<codeph>crt</codeph> with your actual certificate file) to show the
public key in the certificate's subject:</cmd>
<stepresult>
<codeblock>$ -----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEwXfiK2ao/T8EDv02rr1a0xZYKkox
v3FGDltKFLsZNIyTUo5RAhFh8RXy8/hqSlozGfd3pOx/70LeGzbWd/ExQg==
-----END PUBLIC KEY-----</codeblock>
</stepresult>
</step>
<step>
<cmd>Check if the public key generated from the private key is the same as
the public key in the certificate's subject. If they are not the same,
your key doesn't match your certificate. Try to obtain the right key /
certificate.</cmd>
</step>
</steps>
</remedy>
</troubleSolution>
</troublebody>
</troubleshooting>


Re: How to constraint elements of Standard Highlighting domain module #constraints

ekimber@contrext.com
 

If you simply want to disallow the use of specific elements from a domain you can do this in the DTD shell--no need for a separate constraint module.

But note that this does require that you have custom DTD shells (see https://www.xiruss.org/tutorials/dita-specialization/, in particular, Chapter 3, Document Type Shell tutorial).

In the shell DTD you "integrate" domain using domain-integration parameter entities, i.e., (here take from the basetopic.dtd but it will be similar in any of the OASIS-provided DTD shells):

<!-- ============================================================= -->
<!-- DOMAIN EXTENSIONS -->
<!-- ============================================================= -->

...

<!ENTITY % ph "ph |
%hi-d-ph;
">


Here "%hi-d-ph;" is a reference to a parameter entity that includes all the element types from the Highlight domain (base/dtd/highlightDomain.ent):

<!ENTITY % hi-d-ph
"b |
i |
line-through |
overline |
sup |
sub |
tt |
u"
That has the effect of allowing all the elements to occur wherever <ph> is allowed.

This entity, %hi-d-ph, is the "domain integration parameter entity".

Instead of referring to %hi-d-ph in the domain integration parameter entity you can simply refer to the element types you want to allow;

<!-- ============================================================= -->
<!-- DOMAIN EXTENSIONS -->
<!-- ============================================================= -->

...

<!ENTITY % ph "ph |
sup |
sub
">

This is a constraint and, per DITA 1.x rules, should be declared in the @domains attribute just as you would declare a constraint module, but we're removing the @domains attribute in DITA 2.0 and as far as I know no tool will complain that you didn't declare this constraint.

Note that you need to define this constraint in the shell DTD for each topic type you're using.

Cheers,

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


On 8/31/20, 3:21 AM, "Meghana" <main@dita-users.groups.io on behalf of meghan25pathroju@gmail.com> wrote:

Hello Team,
Good Morning!

I am currently working on example:2.5.5.6.3 constrain a domain module. referring to http://docs.oasis-open.org/

use case :The requirement is to apply constraints on dita elements of highlighting domain module and remove them from the DTD files reason being business doesn't want to give access to all the dita elements provided by web-editor,basically limiting element choices for authors.
example: An information architect wants to use only a subset of the elements defined in the highlighting domain. She wants to use <sup>, <sup>but not <b> ,<i>,<line-through>, <overline>, <tt> .She wants to integrate this constraint into the DTD's / document-type shell for tasks


Reference I followed to achieve this: http://docs.oasis-open.org/dita/dita/v1.3/errata02/os/complete/part3-all-inclusive/archSpec/base/example-contraints-subset-domain.html


1. I am not trying to create new DTD schema instead I would like to make use of standard or default highlighting domain module provided by OASIS (//OASIS//ENTITIES DITA 1.3 Highlight Domain//EN" "../../base/dtd/highlightDomain.ent) to constraint <b> ,<i>,<line-through>, <overline>, <tt> and allow <sub>,<sup> elements.
2. The example in document is intended for the users who has custom DTD schema i.e ACME(//ACME//ENTITIES DITA Highlighting Domain Constraint//EN" "acme-HighlightingDomainConstraint.mod")and they would like to restrict the elements from the custom highlighting domain.My requirement is different from the example in the document.
3. I feel the information provided in the document is insufficient and targets the audience who works on custom DTD schema's and it is difficult for the DITA newbie's like me to understand that high level example.Please,guide me on how to achieve above mentioned use case.Please,throw some light on the different ways to achieve this use case.

Thanks,
Meghana Pathroju.


Re: How to constraint elements of Standard Highlighting domain module #constraints

Kristen James Eberlein
 

Hi, Meghana.

I understand your use case well. The problem here is that constraints ONLY can be applied if you are using company-specific document-type shells (DTDs). You CANNOT apply constraints to the out-of-the-box OASIS DTDs.

Depending on the editor that you authors are using, you might be able to hide elements from the authors. This is certainly true of the desktop version of Oxygen XML Editor. It does require creating a custom framework for Oxygen installations.

I am sorry that you found the example in the spec to be difficult. As one of the spec editors, I can reinforce your sense that the target audience is DITA practioners who develop company-specific DTDs, constraints, and specialization -- as well as engineers who design and build DITA processors. The target audience for the spec is not people new to DITA.

While there are now quite a few good books that are resources for people new to DITA, I do not think that any of them delve into the more technical aspects of implementing DITA.

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)

On 8/31/2020 4:21 AM, Meghana wrote:
Hello Team,
Good Morning!

I am currently working on example:2.5.5.6.3 constrain a domain module. referring to  http://docs.oasis-open.org/

use case :The requirement is to apply constraints on dita elements of highlighting domain module and remove them from the DTD files reason being business doesn't want to give access to all the dita elements provided by web-editor,basically limiting element choices for authors.

example
: An information architect wants to use only a subset of the elements defined in the highlighting domain. She wants to use  <sup>, <sup>but not <b> ,<i>,<line-through>, <overline>, <tt> .She wants to integrate this constraint into the DTD's / document-type shell for tasks


  1. I am not trying to create new DTD schema instead I would like to make use of standard or default highlighting domain module provided by OASIS (//OASIS//ENTITIES DITA 1.3 Highlight Domain//EN"  "../../base/dtd/highlightDomain.ent) to constraint  <b> ,<i>,<line-through>, <overline>, <tt> and allow <sub>,<sup> elements.
  2. The example in document is intended for the users who has custom DTD schema i.e ACME(//ACME//ENTITIES DITA Highlighting Domain Constraint//EN" "acme-HighlightingDomainConstraint.mod")and they would like to restrict the elements from the custom highlighting domain.My requirement is different from the example in the document.
  3. I feel the information provided in the document is insufficient and targets the audience who works on custom DTD schema's and it is difficult for the DITA newbie's like me to understand that high level example.Please,guide me on how to achieve above mentioned use case.Please,throw some light on the different ways to achieve this use case.
Thanks,
Meghana Pathroju.


Re: Super Health Secrets

Kristen James Eberlein
 

This member now has been banned.

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)

On 8/31/2020 8:14 AM, Dora Tamilta via groups.io wrote:
When asked about his secret of staying young, Dick Clark replied, ” it’s simple. Pick your parents carefully. “
 
Obviously, you can’t pick your parents, otherwise Ozzie and Harriet would have had thousands of children. However, who your parents are can have a huge impact on how long you live. Diseases that can cut your life short, like heart disease, Alzheimer’s, and most types of cancers, have a strong genetic connection. 
Here is a detailed article that explains how you can avoid or reduce the impact these deadly diseases that you might have inherited.
 

541 - 560 of 46295