Date   

Re: [EXTERNAL] Re: [dita-users] Keyrefs no longer resolved within conrefs #keys #conref

Radu Coravu
 

Hi Jay,

Please see some answers below:

Could you provide details on the differences between the vanilla DITA-OT, and the DITA-OT with the various small fixes bundled in the Oxygen Publishing Englne?

Good question, right now our Oxygen Publishing Engine available on the web site is based on DITA OT 3.5.4.

It has extra patches for:

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

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

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

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

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

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

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

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

On each of those issues I added comments explaining how I attempted to fix things on my side.

Are fixes delivered as jar files to add to the classpath in the plugin.xml?

The fixes are delivered with a special DITA OT plugin named "com.oxygenxml.dost.patches" and they only work with a specific DITA OT version (in this case 3.5.4).
Are these fixes specific to publishing with Oxygen or can they be used for any output type?

The fixes I enumerated above are for any output type, most of them are in the DITA OT pre processing stages which are similar for any output type.


Regards,

Radu

Radu Coravu
Oxygen XML Editor

On 1/22/21 22:44, Jay Sadler wrote:

Hi Radu,

Could you provide details on the differences between the vanilla DITA-OT, and the DITA-OT with the various small fixes bundled in the Oxygen Publishing Englne?

Are fixes delivered as jar files to add to the classpath in the plugin.xml?

Are these fixes specific to publishing with Oxygen or can they be used for any output type?

Jay

 

From: main@dita-users.groups.io <main@dita-users.groups.io> On Behalf Of Radu Coravu via groups.io
Sent: Friday, January 22, 2021 5:53 AM
To: main@dita-users.groups.io
Subject: [EXTERNAL] Re: [dita-users] Keyrefs no longer resolved within conrefs #conref #keys

 

External Email - DO NOT CLICK links or attachments unless you recognize the sender and are expecting the email.


Hi Christina,

Maybe you can create a small sample DITA project exemplifying the problem and attach it to an email.

The DITA OT bundled with Oxygen also comes with various small fixes made to the open source DITA OT distribution.

We deliver it as a separate download named Oxygen Publishing Engine, it is available for download here:

https://www.oxygenxml.com/publishing_engine.html

Maybe you can try to run the transformation from the command line, for example to produce the PDF. If it properly generates the output but the DITA OT 3.5.4 downloaded from the DITA OT web site does not, then probably one of our fixes might responsible for that.

Regards,

Radu

Radu Coravu
Oxygen XML Editor

On 1/22/21 14:27, stinakab via groups.io wrote:

Hi,

We're currently switching from DITA OT 3.4.1 to DITA OT 3.5.4 (the latest version supported by Oxygen 23.0).
We use Oxygen for local builds and use a build server for publishing. We have customization plug-ins.
At first, it looked as if everything ran smoothly. Then we discovered that on the build server <keyword keyrefs="xxx"> are no longer resolved within conref elements.
All other keyrefs resolve properly. It's just the conrefs in which they don't resolve.
It used to work with 3.4.1, but somehow with 3.5.4 there seems to something wrong. In Oxygen 23.0, there are no issues when transformations are run.
This happens with PDF and webhelp responsive outputs.
I don't have the slightest idea why the keyrefs are no longer resolved.
Could anybody help me with this, please?

Christina

 

  


Re: [EXTERNAL] Re: [dita-users] Keyrefs no longer resolved within conrefs #keys #conref

Jay Sadler
 

Hi Radu,

Could you provide details on the differences between the vanilla DITA-OT, and the DITA-OT with the various small fixes bundled in the Oxygen Publishing Englne?

Are fixes delivered as jar files to add to the classpath in the plugin.xml?

Are these fixes specific to publishing with Oxygen or can they be used for any output type?

Jay

 

From: main@dita-users.groups.io <main@dita-users.groups.io> On Behalf Of Radu Coravu via groups.io
Sent: Friday, January 22, 2021 5:53 AM
To: main@dita-users.groups.io
Subject: [EXTERNAL] Re: [dita-users] Keyrefs no longer resolved within conrefs #conref #keys

 

External Email - DO NOT CLICK links or attachments unless you recognize the sender and are expecting the email.


Hi Christina,

Maybe you can create a small sample DITA project exemplifying the problem and attach it to an email.

The DITA OT bundled with Oxygen also comes with various small fixes made to the open source DITA OT distribution.

We deliver it as a separate download named Oxygen Publishing Engine, it is available for download here:

https://www.oxygenxml.com/publishing_engine.html

Maybe you can try to run the transformation from the command line, for example to produce the PDF. If it properly generates the output but the DITA OT 3.5.4 downloaded from the DITA OT web site does not, then probably one of our fixes might responsible for that.

Regards,

Radu

Radu Coravu
Oxygen XML Editor

On 1/22/21 14:27, stinakab via groups.io wrote:

Hi,

We're currently switching from DITA OT 3.4.1 to DITA OT 3.5.4 (the latest version supported by Oxygen 23.0).
We use Oxygen for local builds and use a build server for publishing. We have customization plug-ins.
At first, it looked as if everything ran smoothly. Then we discovered that on the build server <keyword keyrefs="xxx"> are no longer resolved within conref elements.
All other keyrefs resolve properly. It's just the conrefs in which they don't resolve.
It used to work with 3.4.1, but somehow with 3.5.4 there seems to something wrong. In Oxygen 23.0, there are no issues when transformations are run.
This happens with PDF and webhelp responsive outputs.
I don't have the slightest idea why the keyrefs are no longer resolved.
Could anybody help me with this, please?

Christina

 


[ann][webinar] Engage everyone in the technical documentation process #Oxygen

alin_belu@...
 

Hello, 
 
We at Oxygen XML strongly think that anyone can contribute to the technical documentation with the proper collaboration tools! 
 
And next Wednesday (January 27), during the “Engage everyone in the technical documentation process” live webinar, Bogdan Dumitru, software developer at Syncro Soft, will show you how Oxygen Content Fusion is a platform for all, not just for technical writers. 
 
You will see firsthand how it can positively impact the activity of each person involved in the technical documentation process: 
* Technical writers who have full control over the content - the gatekeepers of the documentation source. 
* Subject matter experts (SMEs) who can create and push documentation drafts to technical writers. 
* Users that can now propose changes just by following a link in the published output. 
 
Along with the presented use-cases, this live event will also highlight DITA-specific features as well as some of the new additions brought to Content Fusion 4, in particular the concurrent editing support, allowing unrestricted access to edited files. 
 
This is a free event and you can register at http://www.oxygenxml.com/evs2021-5.html 
 
Make sure to check the full list of our upcoming events: https://www.oxygenxml.com/events_programme.html 
 
Best regards,
Alin
--
Alin Belu
Oxygen XML Editor


Re: Keyrefs no longer resolved within conrefs #keys #conref

Radu Coravu
 

Hi Christina,

Maybe you can create a small sample DITA project exemplifying the problem and attach it to an email.

The DITA OT bundled with Oxygen also comes with various small fixes made to the open source DITA OT distribution.

We deliver it as a separate download named Oxygen Publishing Engine, it is available for download here:

https://www.oxygenxml.com/publishing_engine.html

Maybe you can try to run the transformation from the command line, for example to produce the PDF. If it properly generates the output but the DITA OT 3.5.4 downloaded from the DITA OT web site does not, then probably one of our fixes might responsible for that.

Regards,

Radu

Radu Coravu
Oxygen XML Editor
On 1/22/21 14:27, stinakab via groups.io wrote:

Hi,

We're currently switching from DITA OT 3.4.1 to DITA OT 3.5.4 (the latest version supported by Oxygen 23.0).
We use Oxygen for local builds and use a build server for publishing. We have customization plug-ins.
At first, it looked as if everything ran smoothly. Then we discovered that on the build server <keyword keyrefs="xxx"> are no longer resolved within conref elements.
All other keyrefs resolve properly. It's just the conrefs in which they don't resolve.
It used to work with 3.4.1, but somehow with 3.5.4 there seems to something wrong. In Oxygen 23.0, there are no issues when transformations are run.
This happens with PDF and webhelp responsive outputs.
I don't have the slightest idea why the keyrefs are no longer resolved.
Could anybody help me with this, please?

Christina

  


Keyrefs no longer resolved within conrefs #keys #conref

stinakab
 

Hi,

We're currently switching from DITA OT 3.4.1 to DITA OT 3.5.4 (the latest version supported by Oxygen 23.0).
We use Oxygen for local builds and use a build server for publishing. We have customization plug-ins.
At first, it looked as if everything ran smoothly. Then we discovered that on the build server <keyword keyrefs="xxx"> are no longer resolved within conref elements.
All other keyrefs resolve properly. It's just the conrefs in which they don't resolve.
It used to work with 3.4.1, but somehow with 3.5.4 there seems to something wrong. In Oxygen 23.0, there are no issues when transformations are run.
This happens with PDF and webhelp responsive outputs.
I don't have the slightest idea why the keyrefs are no longer resolved.
Could anybody help me with this, please?

Christina


Re: Allow variables to be referenced from @scope="peer" maps

David Hollis
 

Hi Chris, Eliot,

It's obvious that the two products and their documentation share an environment because there is a mapref from one to the other. With that in mind, I'm struggling to understand why you are not keen to use one of the alternatives that you mention.

It might seem like a good idea for each product to manage its own keys and content, but surely that leads to product silos? One of the strengths of DITA is that it breaks silos down.

I'm also a little concerned that the solution Eliot suggests could lead to quite complicated key processing?

Maybe I'm missing something?

David

To implement this you have to do all the preprocessing on all the peer maps referenced so that you know what the key space in each referenced peer map is.

That would be very inefficient in a naïve implementation because every time you ran map A that references peer B you'd also have to process peer B.

An obvious solution is to implement some kind of "key service" that maintains a persistent resolved key space for each map such that a processor can just ask for the resolved value of a given key in a given map. Of course, there are a number of potential issues here, including: how do you know when to update your persistent store? How do you handle runtime conditions, in particular, active filtering settings (DITAVAL)?

You start to see that this is the domain of content management where you have systems that have general knowledge of bodies of DITA content, track their status, versions, etc.

A relatively simplistic key service probably wouldn't be that difficult to implement (and my now-fallow DITA for Small Teams link manager application was working towards being a key service, among other things) but probably way outside the scope of the Open Toolkit project.

I've thought for a while that it would be useful to have a general key access API that defines the minimum features for DITA key stores. Given such an API a tool like Open Toolkit could have general key store requests that are then resolved against whatever key store you happen to have made a available, if any. A REST API could be implemented in any number of common technologies (Java, JavaScript, XQuery, etc.).

Another brute force solution would be to have Open Toolkit write out an easy-to-access representation of a given publication's key space whenever it's processed (or on request as a runtime option). When resolving peer references, could then try to find the key space data file and use it if found. This would leave it up to users to make sure that the key spaces were up to date, basically, processing every publication once and then processing them a second time to ensure they've used up to date key spaces from any peer publications.

Essentially, using peer maps takes you from having a collection of otherwise-independent publications to having a system of interdependent publications. As soon as you have that you have unavoidable management problems inherent in trying to produce deliverables from these interdependent publications, problems that are solvable but require some kind of content management system that maintains knowledge about all the publications, their components, their versions, their relationships to each other, provides processing optimizations (indexes, caches, etc.).

Or you have to create ad-hoc solutions that take advantage of simplifying assumptions you can make about your content or constraints you can impose on your content (and its authors). For example, for your purposes, it might be sufficient to have some kind of script that reads peer maps and generates sets of key definitions to be used in the referencing publications as local-scope key definitions. That's relatively easy to do but you then have to keep these generated key definition sets up to date as the publications are modified.

Cheers,

E.

--
Eliot Kimber
http://contrext.com


On 1/21/21, 5:39 PM, "Chris Papademetrious" <main@dita-users.groups.io on behalf of chrispitude@gmail.com> wrote:

Hi everyone,

This is an FYI for an enhancement request I filed for the DITA-OT, in case anyone else would find it useful too:

Allow variables to be referenced from @scope="peer" maps #3685 <https://github.com/dita-ot/dita-ot/issues/3685>

The text is as follows:
Description
I have two books, bookA and bookB. bookA references bookB as a @scope="peer" map:

<map>
<title>Book A Map</title>
<mapref href="bookB.ditamap" scope="peer" keyscope="bookB" processing-role="resource-only"/>
<!-- ^^^^^^^^^^^^^ ^^^^ ^^^^^
...
</map>


In a topic in bookA, I would like to reference a "Product" variable from bookB:

<p>BookB provides more information on <ph keyref="bookB.Product"/>.</p>
<!-- ^^^^^^^^^^^^^ -->

Unfortunately, @scope="peer" suppresses all bookB content from the bookA transformation - topic content and variable definitions.

This enhancement requests that keyscoped @scope="peer" maps pull their keys (but not topics) from the referenced map into the current map.

To test this, unarchive the following testcase:

#### ditaot_keys_from_peer_books.zip ####

then run

dita -i bookA.ditamap -i bookA.ditamap -f html5 -o out
Possible Solution
I tried implementing a proof-of-concept solution, which you can see in the testcase directory as follows:

diff maprefImpl.xsl.ORIG maprefImpl.xsl.NEW

The attempt was to remember when we're in a @scope="peer-with-keys" context, that would keep all mapref contents except topic references. Unfortunately, even this naive attempt did not work - the variables still did not resolve, and bookB topics still showed up in the bookA output directory. (You will need to change @scope="peer" to @scope="peer-with-keys" to try this proof-of-concept on the provided testcase.)
Potential Alternatives
I am aware of warehouse topics, shared key definition files, etc. However, those are not a good fit for this need. This enhancement is for the case where we're already referencing a peer book and that book already defines the variables we want (for its own use), and we simply want to access them as well.


Re: Insert current timestamp as a value to an attribute?

Radu Coravu
 

Hello Wito,

I'm glad this works for you now, I will correct the screenshot in the blog post.

Regards,

Radu

Radu Coravu
Oxygen XML Editor
On 1/22/21 12:07, Wito Zoerkler wrote:

Hello Radu,
 
Thank you very much for your advice. With the quoted element, it now also works for me with the Activation XPath.
Could it be that the quotation marks for the "created" element in the Activation XPath are missing in the example screenshot under Adding a Custom Author Action to the Content Completion Window (oxygenxml.com)?
 
Best regards
Wito

  


Re: Insert current timestamp as a value to an attribute?

Wito Zoerkler
 

Hello Radu,
 
Thank you very much for your advice. With the quoted element, it now also works for me with the Activation XPath.
Could it be that the quotation marks for the "created" element in the Activation XPath are missing in the example screenshot under Adding a Custom Author Action to the Content Completion Window (oxygenxml.com)?
 
Best regards
Wito


Re: Allow variables to be referenced from @scope="peer" maps

ekimber@contrext.com
 

To implement this you have to do all the preprocessing on all the peer maps referenced so that you know what the key space in each referenced peer map is.

That would be very inefficient in a naïve implementation because every time you ran map A that references peer B you'd also have to process peer B.

An obvious solution is to implement some kind of "key service" that maintains a persistent resolved key space for each map such that a processor can just ask for the resolved value of a given key in a given map. Of course, there are a number of potential issues here, including: how do you know when to update your persistent store? How do you handle runtime conditions, in particular, active filtering settings (DITAVAL)?

You start to see that this is the domain of content management where you have systems that have general knowledge of bodies of DITA content, track their status, versions, etc.

A relatively simplistic key service probably wouldn't be that difficult to implement (and my now-fallow DITA for Small Teams link manager application was working towards being a key service, among other things) but probably way outside the scope of the Open Toolkit project.

I've thought for a while that it would be useful to have a general key access API that defines the minimum features for DITA key stores. Given such an API a tool like Open Toolkit could have general key store requests that are then resolved against whatever key store you happen to have made a available, if any. A REST API could be implemented in any number of common technologies (Java, JavaScript, XQuery, etc.).

Another brute force solution would be to have Open Toolkit write out an easy-to-access representation of a given publication's key space whenever it's processed (or on request as a runtime option). When resolving peer references, could then try to find the key space data file and use it if found. This would leave it up to users to make sure that the key spaces were up to date, basically, processing every publication once and then processing them a second time to ensure they've used up to date key spaces from any peer publications.

Essentially, using peer maps takes you from having a collection of otherwise-independent publications to having a system of interdependent publications. As soon as you have that you have unavoidable management problems inherent in trying to produce deliverables from these interdependent publications, problems that are solvable but require some kind of content management system that maintains knowledge about all the publications, their components, their versions, their relationships to each other, provides processing optimizations (indexes, caches, etc.).

Or you have to create ad-hoc solutions that take advantage of simplifying assumptions you can make about your content or constraints you can impose on your content (and its authors). For example, for your purposes, it might be sufficient to have some kind of script that reads peer maps and generates sets of key definitions to be used in the referencing publications as local-scope key definitions. That's relatively easy to do but you then have to keep these generated key definition sets up to date as the publications are modified.

Cheers,

E.

--
Eliot Kimber
http://contrext.com


On 1/21/21, 5:39 PM, "Chris Papademetrious" <main@dita-users.groups.io on behalf of chrispitude@gmail.com> wrote:

Hi everyone,

This is an FYI for an enhancement request I filed for the DITA-OT, in case anyone else would find it useful too:

Allow variables to be referenced from @scope="peer" maps #3685 <https://github.com/dita-ot/dita-ot/issues/3685>

The text is as follows:
Description
I have two books, bookA and bookB. bookA references bookB as a @scope="peer" map:

<map>
<title>Book A Map</title>
<mapref href="bookB.ditamap" scope="peer" keyscope="bookB" processing-role="resource-only"/>
<!-- ^^^^^^^^^^^^^ ^^^^ ^^^^^
...
</map>


In a topic in bookA, I would like to reference a "Product" variable from bookB:

<p>BookB provides more information on <ph keyref="bookB.Product"/>.</p>
<!-- ^^^^^^^^^^^^^ -->

Unfortunately, @scope="peer" suppresses all bookB content from the bookA transformation - topic content and variable definitions.

This enhancement requests that keyscoped @scope="peer" maps pull their keys (but not topics) from the referenced map into the current map.

To test this, unarchive the following testcase:

#### ditaot_keys_from_peer_books.zip ####

then run

dita -i bookA.ditamap -i bookA.ditamap -f html5 -o out
Possible Solution
I tried implementing a proof-of-concept solution, which you can see in the testcase directory as follows:

diff maprefImpl.xsl.ORIG maprefImpl.xsl.NEW

The attempt was to remember when we're in a @scope="peer-with-keys" context, that would keep all mapref contents except topic references. Unfortunately, even this naive attempt did not work - the variables still did not resolve, and bookB topics still showed up in the bookA output directory. (You will need to change @scope="peer" to @scope="peer-with-keys" to try this proof-of-concept on the provided testcase.)
Potential Alternatives
I am aware of warehouse topics, shared key definition files, etc. However, those are not a good fit for this need. This enhancement is for the case where we're already referencing a peer book and that book already defines the variables we want (for its own use), and we simply want to access them as well.


Allow variables to be referenced from @scope="peer" maps

Chris Papademetrious
 

Hi everyone,

This is an FYI for an enhancement request I filed for the DITA-OT, in case anyone else would find it useful too:

Allow variables to be referenced from @scope="peer" maps #3685

The text is as follows:

Description

I have two books, bookA and bookB. bookA references bookB as a @scope="peer" map:

<map>
  <title>Book A Map</title>
  <mapref href="bookB.ditamap" scope="peer" keyscope="bookB" processing-role="resource-only"/>
  <!--          ^^^^^^^^^^^^^         ^^^^            ^^^^^
  ...
</map>


In a topic in bookA, I would like to reference a "Product" variable from bookB:

<p>BookB provides more information on <ph keyref="bookB.Product"/>.</p>
<!--                                              ^^^^^^^^^^^^^ -->

Unfortunately, @scope="peer" suppresses all bookB content from the bookA transformation - topic content and variable definitions.

This enhancement requests that keyscoped @scope="peer" maps pull their keys (but not topics) from the referenced map into the current map.

To test this, unarchive the following testcase:

#### ditaot_keys_from_peer_books.zip ####

then run

dita -i bookA.ditamap -i bookA.ditamap -f html5 -o out

Possible Solution

I tried implementing a proof-of-concept solution, which you can see in the testcase directory as follows:

diff maprefImpl.xsl.ORIG maprefImpl.xsl.NEW

The attempt was to remember when we're in a @scope="peer-with-keys" context, that would keep all mapref contents except topic references. Unfortunately, even this naive attempt did not work - the variables still did not resolve, and bookB topics still showed up in the bookA output directory. (You will need to change @scope="peer" to @scope="peer-with-keys" to try this proof-of-concept on the provided testcase.)

Potential Alternatives

I am aware of warehouse topics, shared key definition files, etc. However, those are not a good fit for this need. This enhancement is for the case where we're already referencing a peer book and that book already defines the variables we want (for its own use), and we simply want to access them as well.


links within a chunked map?

Tonia
 

Hi all,
I'm having an issue with chunking a map and the internal links not working.

I have a map that I want to generate to one HTML file, and that is working. However, I coded a mini-toc for navigation (because the child topics don't show up in the main toc, by my design).  The xref links are breaking in the generated HTML and are just dead.

Part of me thinks this makes sense because the file hasn't been generated as a separate HTML file that can be linked to, but is there a workaround for this?

I hope I'm explaining it well enough.

Here's a copy of my map:

<map><title>Recycle Bin</title>
   
    <topicref href="../topics/c-recycle-bin.dita" chunk="to-content">
        <topicref href="../topics/c-bulk-actions-recycle-bin.dita" toc="no"/>
        <topicref href="../topics/t-filter-recycle-bin.dita" toc="no"/>
        <topicref href="../topics/t-modify-columns-recycle-bin.dita" toc="no"/>
    </topicref>
</map>

And within the c-recycle-bin.dita file, I have a list of links like this:

  <p>This section includes the following topics:</p>
    <ul id="ul_qsm_cw5_j4b">
      <li><xref href="c-recycle-bin-bulk-actions.dita"></xref></li>
      <li><xref href="t-filter-recycle-bin.dita"></xref></li>
      <li><xref href="t-modify-columns-recycle-bin.dita"></xref></li>
</ul>


What has to be done for this to work upon generation with the chunk element?

Thanks for your help,
Tonia

Rally Software Content Experience Lead


Re: Strange Validation Error

ekimber@contrext.com
 

The message is definitely not an XML validation rule and as far as I know not a DITA-defined rule either unless you're doing "keyname/topicid", in which case it's not a good key reference because you cannot reference a topic by ID as part of a key reference to a different (or the same) topic.

DITA does not disallow a key and an ID to be the same and it does allow element IDs to be specified as part of key references of the form "{keyname}/{elementId}" in order to address elements within topics using keys.

However, it does not allow "{keyname}{topicId}" since you can simply associate a key with the topic--that may be what's being complained about.

Here's the relevant text from the DITA 1.3 spec:

3.12.13.3 The @keyref attribute

The @keyref attribute provides an indirect, late-bound reference to topics, to collections of topics (ditabase), to
maps, to referenceable portions of maps, to non-DITA documents, to external URIs, or to XML content contained
within a key definition topic reference. When the DITA content is processed, the key references are resolved
using key definitions from DITA maps.

For elements that only refer to topics or non-DITA resources, the value of the @keyref attribute is a key name.
For elements that can refer to elements within maps or topics, the value of the @keyref attribute is a key name,
a slash ("/"), and the ID of the target element, where the key name must be bound to either the map or topic that
contains the target element.

Cheers,

E.

--
Eliot Kimber
http://contrext.com


On 1/20/21, 8:25 AM, "Wayne Brissette" <main@dita-users.groups.io on behalf of wbrisett@att.net> wrote:



I've run into an issue I haven't seen before and I'm wondering if
somebody can shed some light on it for me.



We have a bunch of autogenerated content. IDs for topics are picked up
by the title with some substitution for invalid characters.



We have a topic with the ID of <reference id="const">



Elsewhere in the document we have this:



<xref keyref="const_access" >const</xref>.


During validation this fails due to this:



Key reference to a topic must not contain topic ID "const".



I've never run into this before. I've tried changing the keyref an key
slightly adding additional things to it, but it still fails with this
error.



I should point out that this is a manual validation done in oXygen
editor, but I don't think oXygen is doing anything out of the norm here.




Anybody have any ideas on this one?



-Wayne


Re: Strange Validation Error

Wayne Brissette
 

Sadly David, that's my mis-typing. ;)



David Hollis wrote on 2021-01-20 08:59:

Hi Wayne,

I admit I don't know all the XML validation rules, but I notice that there's a space between end quote and end angle bracket:

_access" >

That couldn't be it?!

HTH,
David


Re: Strange Validation Error

David Hollis
 

Hi Wayne,

I admit I don't know all the XML validation rules, but I notice that there's a space between end quote and end angle bracket:

_access" >

That couldn't be it?!

HTH,
David


I've run into an issue I haven't seen before and I'm wondering if somebody can shed some light on it for me.

We have a bunch of autogenerated content. IDs for topics are picked up by the title with some substitution for invalid characters.

We have a topic with the ID of <reference id="const">

Elsewhere in the document we have this:

<xref keyref="const_access" >const</xref>.

During validation this fails due to this:

Key reference to a topic must not contain topic ID "const".

I've never run into this before. I've tried changing the keyref an key slightly adding additional things to it, but it still fails with this error.

I should point out that this is a manual validation done in oXygen editor, but I don't think oXygen is doing anything out of the norm here.

Anybody have any ideas on this one?

-Wayne


Strange Validation Error

Wayne Brissette
 

I've run into an issue I haven't seen before and I'm wondering if somebody can shed some light on it for me.

We have a bunch of autogenerated content. IDs for topics are picked up by the title with some substitution for invalid characters.

We have a topic with the ID of <reference id="const">

Elsewhere in the document we have this:

<xref keyref="const_access" >const</xref>.

During validation this fails due to this:

Key reference to a topic must not contain topic ID "const".

I've never run into this before. I've tried changing the keyref an key slightly adding additional things to it, but it still fails with this error.

I should point out that this is a manual validation done in oXygen editor, but I don't think oXygen is doing anything out of the norm here.

Anybody have any ideas on this one?

-Wayne


Re: Insert current timestamp as a value to an attribute?

Radu Coravu
 

Hello Wito,

You can see here examples of how the function is called, it needs to have a quoted literal as a parameter:

https://www.oxygenxml.com/doc/versions/23.0/ug-editor/topics/oxy-allows-child-element.html

About your question of needing an activation xpath, when the content completion window is populated, if the action's xpath condition is not fulfilled, the action is not added to the content completion window. I know that in your case the action is a simple element but there might be more complex actions which may require more complex activation xpaths (for example the action may insert an element somewhere else in the document or it may insert multiple elements or text) so this extra added flexibility is not bad.

Regards,

Radu

Radu Coravu
Oxygen XML Editor
On 1/18/21 18:19, Wito Zoerkler wrote:

Hi Radu,

Thank you for the link, it was very helpful.

However, when I enter an 'Activation XPath', I get the following error message ('rev-history' is the specialized element).


If I don't enter an 'Activation XPath', it works.
Why would I need an 'Activation XPath' when I call the operation via Content Completion?

Best regards
Wito

  


Re: Insert current timestamp as a value to an attribute?

Wito Zoerkler
 

Hi Radu,

Thank you for the link, it was very helpful.

However, when I enter an 'Activation XPath', I get the following error message ('rev-history' is the specialized element).


If I don't enter an 'Activation XPath', it works.
Why would I need an 'Activation XPath' when I call the operation via Content Completion?

Best regards
Wito


Re: Insert current timestamp as a value to an attribute?

Radu Coravu
 

Hi Wito,

Maybe this article on the Oxygen XML Blog will help:

https://blog.oxygenxml.com/topics/custom-author-action-content-completion.html

Regards,

Radu

Radu Coravu
Oxygen XML Editor
On 1/15/21 17:26, Wito Zoerkler wrote:

Hello,
 
How can I insert the current timestamp as a value to an attribute?
 
Example: A specialized element is inserted and it must contain a new (specialized) attribute (e.g. 'Timestamp').
What would be the best way to insert the current timestamp to that attribute? Schematron or an Oxygen action? 
Has anyone ever had the case of having to add a timestamp to an attribute?
 
Environment: DTD-based vocabulary modules, Oxygen as editor
 
Best regards
Wito

  


Insert current timestamp as a value to an attribute?

Wito Zoerkler
 

Hello,
 
How can I insert the current timestamp as a value to an attribute?
 
Example: A specialized element is inserted and it must contain a new (specialized) attribute (e.g. 'Timestamp').
What would be the best way to insert the current timestamp to that attribute? Schematron or an Oxygen action? 
Has anyone ever had the case of having to add a timestamp to an attribute?
 
Environment: DTD-based vocabulary modules, Oxygen as editor
 
Best regards
Wito


[ann][webinar] Transforming DITA documents to PDF, Part 1 - Page Definitions, Cover Page and PDF Metadata (January 20) #Oxygen

alin_belu@...
 

Hello, 
 
Next Wednesday, on January 20th, join us for the debut of our new live instructional webinar series titled “Transforming DITA documents to PDF”! 
 
The first entry of this series, “Page Definitions, Cover Page and PDF Metadata”, was created for the people who want to publish their DITA books and maps in PDF but are struggling with the process.  
 
Understanding the not-so-easy path that a complete novice needs to take, during this 1-hour webinar, Julien Lacour (software developer at Syncro Soft) will teach you step-by-step how to customize your PDF publications and make them compliant with all your company’s documentation requirements. Quick, easy, and fun! 
 
At the end of this crash-course, you will be able to: 
* Define specific pages (frontmatter/backmatter, chapters, indexes, etc.). 
* Set page sizes and page margins. 
* Place fixed content in headers/footers. 
* Create a cover page with little to no effort. 
* Add metadata into the final PDF to apply searchable keywords into your document and so much more. 
 
This is a free event and you can register at http://www.oxygenxml.com/evs2021-2.html 
 
Make sure to check the full list of our upcoming events: https://www.oxygenxml.com/events_programme.html 
 
Best regards,
Alin

--
Alin Belu
Oxygen XML Editor

341 - 360 of 46295