keyref and conkeyref best practice and processing flow


Dan Vint
 

I've been googling around for information on using keyref and conkeyref and not finding confirmation for something I thought I saw.

I believe there is a recommendation (maybe requirement) that you can't nest these proceses. My testing seems to say it isn't supported, but maybe there is a feature I've not setup properly.

We are trying to build a para that will be keyconref'd into a variety of locations. In this para we are also trying to use variables for the product names that are defined with keys.

I've done the following:
- confirmed that copying the para into the referencing topic allows the product name variable to work - so that key is configured properly
- conkeyrefing the para in, the product variable is not resolved. I don't even get a message in the OT log that indicates it is being seen.

I'm torn between saying this is a useful feature to have if it isn't supported, but on the other hand I can see where it might cause an infinite loop if these are allowed to nest.

I'm mainly just trying to confirm that this is the way it is and that I haven't missed something.

thanks
..dan


Radu Coravu
 

Hi Dan,

This should work. Please make sure that the topic inside which that reused <p> element is located is referenced in the DITA Map as a topicref with the "processing-role='resource-only'" attribute set on it:

https://github.com/dita-ot/dita-ot/issues/3546

If that did not help maybe you can give us more details like:

1) The DITA OT version you are using.

2) The output format you are publishing to.

3) Attach a small sample DITA project exemplifying the problem.

Regards,
Radu

Radu Coravu
Oxygen XML Editor

On 8/21/20 7:57 PM, Dan Vint wrote:
I've been googling around for information on using keyref and conkeyref and not finding confirmation for something I thought I saw.

I believe there is a recommendation (maybe requirement) that you can't nest these proceses. My testing seems to say it isn't supported, but maybe there is a feature I've not setup properly.

We are trying to build a para that will be keyconref'd into a variety of locations. In this para we are also trying to use variables for the product names that are defined with keys.

I've done the following:
- confirmed that copying the para into the referencing topic allows the product name variable to work - so that key is configured properly
- conkeyrefing the para in, the product variable is not resolved. I don't even get a message in the OT log that indicates it is being seen.

I'm torn between saying this is a useful feature to have if it isn't supported, but on the other hand I can see where it might cause an infinite loop if these are allowed to nest.

I'm mainly just trying to confirm that this is the way it is and that I haven't missed something.

thanks
..dan


DANIEL ESSIET
 

I am new to this. I am going to learn from the scratch. Presently, l work as a business journalist with The Nation Newspaper, Lagos.
Regards,
Daniel Essiet

On Mon, Aug 24, 2020, 6:47 AM Radu Coravu <radu_coravu@...> wrote:
Hi Dan,

This should work. Please make sure that the topic inside which that
reused <p> element is located is referenced in the DITA Map as a
topicref with the "processing-role='resource-only'" attribute set on it:

https://github.com/dita-ot/dita-ot/issues/3546

If that did not help maybe you can give us more details like:

1) The DITA OT version you are using.

2) The output format you are publishing to.

3) Attach a small sample DITA project exemplifying the problem.

Regards,
Radu

Radu Coravu
Oxygen XML Editor

On 8/21/20 7:57 PM, Dan Vint wrote:
> I've been googling around for information on using keyref and
> conkeyref and not finding confirmation for something I thought I saw.
>
> I believe there is a recommendation (maybe requirement) that you can't
> nest these proceses. My testing seems to say it isn't supported, but
> maybe there is a feature I've not setup properly.
>
> We are trying to build a para that will be keyconref'd into a variety
> of locations. In this para we are also trying to use variables for the
> product names that are defined with keys.
>
> I've done the following:
> - confirmed that copying the para into the referencing topic allows
> the product name variable to work - so that key is configured properly
> - conkeyrefing the para in, the product variable is not resolved. I
> don't even get a message in the OT log that indicates it is being seen.
>
> I'm torn between saying this is a useful feature to have if it isn't
> supported, but on the other hand I can see where it might cause an
> infinite loop if these are allowed to nest.
>
> I'm mainly just trying to confirm that this is the way it is and that
> I haven't missed something.
>
> thanks
> ..dan
>
>
>





Julio J Vazquez
 

If you're new to this, I suggest you purchase at least one of the books about the subject to avoid trying to assemble knowledge from disparate questions. Depending on what you want to learn, there are plenty of resources to help you. 

Julio J. Vazquez


Dan Vint
 

Thanks for the pointer. I hadn't paid attention to how our ccms created the system generated keys were defined. It turns out they use local. I'm asking them why as even without this issue, resource-only seems to be the correct choice.



Sent from my Verizon, Samsung Galaxy smartphone


-------- Original message --------
From: Radu Coravu <radu_coravu@...>
Date: 8/23/20 10:47 PM (GMT-08:00)
To: main@dita-users.groups.io, dita-users@groups.io
Subject: Re: [dita-users] keyref and conkeyref best practice and processing flow

Hi Dan,

This should work. Please make sure that the topic inside which that
reused <p> element is located is referenced in the DITA Map as a
topicref with the "processing-role='resource-only'" attribute set on it:

https://github.com/dita-ot/dita-ot/issues/3546

If that did not help maybe you can give us more details like:

1) The DITA OT version you are using.

2) The output format you are publishing to.

3) Attach a small sample DITA project exemplifying the problem.

Regards,
Radu

Radu Coravu
Oxygen XML Editor

On 8/21/20 7:57 PM, Dan Vint wrote:
> I've been googling around for information on using keyref and
> conkeyref and not finding confirmation for something I thought I saw.
>
> I believe there is a recommendation (maybe requirement) that you can't
> nest these proceses. My testing seems to say it isn't supported, but
> maybe there is a feature I've not setup properly.
>
> We are trying to build a para that will be keyconref'd into a variety
> of locations. In this para we are also trying to use variables for the
> product names that are defined with keys.
>
> I've done the following:
> - confirmed that copying the para into the referencing topic allows
> the product name variable to work - so that key is configured properly
> - conkeyrefing the para in, the product variable is not resolved. I
> don't even get a message in the OT log that indicates it is being seen.
>
> I'm torn between saying this is a useful feature to have if it isn't
> supported, but on the other hand I can see where it might cause an
> infinite loop if these are allowed to nest.
>
> I'm mainly just trying to confirm that this is the way it is and that
> I haven't missed something.
>
> thanks
> ..dan
>
>
>





DANIEL ESSIET
 

Please, l am business journalist trying to transit to technical writing. Where should l start from? I hold a BA Mass Communications and a PGD BA. I have passed a few Google digital certification.
Please advise me.
Kind regards,
Daniel Essiet
Lagos

On Tue, Aug 25, 2020, 11:38 PM Dan Vint <dvint@...> wrote:
Thanks for the pointer. I hadn't paid attention to how our ccms created the system generated keys were defined. It turns out they use local. I'm asking them why as even without this issue, resource-only seems to be the correct choice.



Sent from my Verizon, Samsung Galaxy smartphone


-------- Original message --------
From: Radu Coravu <radu_coravu@...>
Date: 8/23/20 10:47 PM (GMT-08:00)
Subject: Re: [dita-users] keyref and conkeyref best practice and processing flow

Hi Dan,

This should work. Please make sure that the topic inside which that
reused <p> element is located is referenced in the DITA Map as a
topicref with the "processing-role='resource-only'" attribute set on it:

https://github.com/dita-ot/dita-ot/issues/3546

If that did not help maybe you can give us more details like:

1) The DITA OT version you are using.

2) The output format you are publishing to.

3) Attach a small sample DITA project exemplifying the problem.

Regards,
Radu

Radu Coravu
Oxygen XML Editor

On 8/21/20 7:57 PM, Dan Vint wrote:
> I've been googling around for information on using keyref and
> conkeyref and not finding confirmation for something I thought I saw.
>
> I believe there is a recommendation (maybe requirement) that you can't
> nest these proceses. My testing seems to say it isn't supported, but
> maybe there is a feature I've not setup properly.
>
> We are trying to build a para that will be keyconref'd into a variety
> of locations. In this para we are also trying to use variables for the
> product names that are defined with keys.
>
> I've done the following:
> - confirmed that copying the para into the referencing topic allows
> the product name variable to work - so that key is configured properly
> - conkeyrefing the para in, the product variable is not resolved. I
> don't even get a message in the OT log that indicates it is being seen.
>
> I'm torn between saying this is a useful feature to have if it isn't
> supported, but on the other hand I can see where it might cause an
> infinite loop if these are allowed to nest.
>
> I'm mainly just trying to confirm that this is the way it is and that
> I haven't missed something.
>
> thanks
> ..dan
>
>
>





Dan Vint
 

This response is not exactly correct. Something else is going on. I thought local was in the processing-role but that is in scope. Processing-role isn’t defined and is supposed to default to resource-only. I’m still researching what is going on.

 

 

 

From: main@dita-users.groups.io <main@dita-users.groups.io> On Behalf Of Dan Vint
Sent: Tuesday, August 25, 2020 3:39 PM
To: main@dita-users.groups.io; dita-users@groups.io
Cc: dvint@...
Subject: Re: [dita-users] keyref and conkeyref best practice and processing flow

 

Thanks for the pointer. I hadn't paid attention to how our ccms created the system generated keys were defined. It turns out they use local. I'm asking them why as even without this issue, resource-only seems to be the correct choice.

 

 

 

Sent from my Verizon, Samsung Galaxy smartphone

 

 

-------- Original message --------

From: Radu Coravu <radu_coravu@...>

Date: 8/23/20 10:47 PM (GMT-08:00)

Subject: Re: [dita-users] keyref and conkeyref best practice and processing flow

 

Hi Dan,

This should work. Please make sure that the topic inside which that
reused <p> element is located is referenced in the DITA Map as a
topicref with the "processing-role='resource-only'" attribute set on it:

https://github.com/dita-ot/dita-ot/issues/3546

If that did not help maybe you can give us more details like:

1) The DITA OT version you are using.

2) The output format you are publishing to.

3) Attach a small sample DITA project exemplifying the problem.

Regards,
Radu

Radu Coravu
Oxygen XML Editor

On 8/21/20 7:57 PM, Dan Vint wrote:
> I've been googling around for information on using keyref and
> conkeyref and not finding confirmation for something I thought I saw.
>
> I believe there is a recommendation (maybe requirement) that you can't
> nest these proceses. My testing seems to say it isn't supported, but
> maybe there is a feature I've not setup properly.
>
> We are trying to build a para that will be keyconref'd into a variety
> of locations. In this para we are also trying to use variables for the
> product names that are defined with keys.
>
> I've done the following:
> - confirmed that copying the para into the referencing topic allows
> the product name variable to work - so that key is configured properly
> - conkeyrefing the para in, the product variable is not resolved. I
> don't even get a message in the OT log that indicates it is being seen.
>
> I'm torn between saying this is a useful feature to have if it isn't
> supported, but on the other hand I can see where it might cause an
> infinite loop if these are allowed to nest.
>
> I'm mainly just trying to confirm that this is the way it is and that
> I haven't missed something.
>
> thanks
> ..dan
>
>
>