Pages: 1
Print
Author Topic: Update type attributes?  (Read 4088 times)
gcrews
Member

Posts: 265


« on: May 10, 2013, 09:22:38 AM »

Is there any way to refresh the type attributes on maps with XMetaL? Currently a compile we run has over 300 warning about “The type attribute on a topicref element does not match the target topic”. I swear somehow I’ve gotten the map editor or something in XMetaL to update the type attribute on all the topicref type attributes by refreshing references or something but I can’t seem to get it to do it now.


I have the same question about the type attributes xrefs, the same compile has about 50 warnings of “The type attribute on a xref element does not match the target element”.  Is there any way when opening a DITA files to update the xrefs with the correct type attribute or even just remove the type attribute?
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2580



WWW
« Reply #1 on: May 10, 2013, 11:21:14 AM »

Which version of the software are you running?
Logged
gcrews
Member

Posts: 265


« Reply #2 on: May 10, 2013, 04:57:45 PM »

Sorry forgot to mention,
XMetaL(R) Author Enterprise 7.0
Version#: 7.0.0.111
DITA 1.1 Mode

Hum now that I think about it more, maybe it’s the format or scope attribute that I’m thinking of that XMetaL goes and corrects and updates when I open a map.

Hum I did a little analysis and it it looks like 90% of our topicrefs have the type attribute set and10% don’t.  It looks like all the maps that cause build warning about the type attribute not being correct are all recently work on maps.  

This seems to correspond with when we updated to Xmetal 7. Do topicref tags no longer get the type attribute set in 7? Is there any way to set it to always give a type attribute since if there isn’t one it inherits from an ancestor and may likely be incorrect?


The DITA-OT warning:
“ [DOTX019W][WARN]: The type attribute on a topicref element does not match the target topic. The type attribute was set to 'concept', but the topicref points to a more specific 'task' topic. This may cause your links to sort incorrectly in the output. Note that the type attribute is inherited in maps, so the value 'concept' may come from an ancestor topicref. Check and make the type of topicref match with the actual type of topic.”
« Last Edit: May 10, 2013, 05:37:57 PM by gcrews » Logged
gcrews
Member

Posts: 265


« Reply #3 on: May 14, 2013, 04:51:31 PM »

Have you had a chance to look at this?

I think I’m going to have to end up writing a tool that goes though all our maps in out CMS and corrects the type, format, and scope attributes on all our maps. There are are over 600 build warning about it right now. We also ran into an issue where a topicref was inheriting the wrong format attribute and therefor none of children links were being rendered and yet there is absolutely no toolkit warning or error about it.  

I was only able to figure it out after digging into the temp build xml files. Xmetal Topic Reference Properties dialog incorrectly shows that the format attribute is set on topicrefs. The actual topicref code in notepad was:
          <topicref href="file.xml" navtitle="File Title" scope="local"/>

Yet when we were looking at the “Topic Reference Properties” dialog general and preview tab, it shows format="dita" as being set when it is not. Xmetal correctly set it after I deleted a character and added it back and then pressed ok.
« Last Edit: May 14, 2013, 05:02:56 PM by gcrews » Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2580



WWW
« Reply #4 on: May 15, 2013, 03:30:17 PM »

I see. Yes, the dialog has been altered. There is a dropdown list near the bottom of the dialog you can use to to set a few commonly used sets of values for these attributes.
Logged
gcrews
Member

Posts: 265


« Reply #5 on: June 03, 2013, 05:22:52 PM »

Is there a way to tell XMetaL 7 to put the type attribute on topicref when editing maps the way Xmetal 6 did? It seems XMetaL 7 doesn’t even care about setting the type attribute anymore.

I just spent most of th day cleaning up build warning because of 200+ incorrectly inherited type attributes. I could definitely tell that nearly all the locations were  recently added or changed content.
XMetaL(R) Author Enterprise 7.0
Version#: 7.0.0.111
DITA 1.1 Mode
Logged
schwamkrug
Member

Posts: 33


« Reply #6 on: June 04, 2013, 01:15:47 PM »

I ran into a similar issue where XMetaL 6 will insert one of the OOTB topic types (concept/task/reference), even if the topicref is to a specialized topic type. From a pure DITA perspective, the @type attribute is optional, so I made a startup macro to disable @type attribute insertion altogether. I've attached my macro, in case it helps. Maybe it can be hacked to always insert the type attribute?

I think your issue might be because @type attributes, if unspecified, are inherited from the parent topicref? Given this map code:

<topicref href="someTask.dita" type="task">
   <topicref href="someConcept.dita" />
</topicref>

I believe the inner topicref will get type="task" added by DITA OT preprocessing, even though the inner topicref is to a concept:

<topicref href="someTask.dita" type="task">
   <topicref href="someConcept.dita" type="task" />
</topicref>


* preventTypeAttributeInsertion.zip (1.42 KB - downloaded 199 times.)
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2580



WWW
« Reply #7 on: June 04, 2013, 01:45:33 PM »

There are several reasons this was altered, but primarily it was to make the UI work better for clients that have specialized DITA where they might have made up any topic type and wish to insert a custom value, for clients that do not wish to have this value set at all, and for clients that use other custom values instead for other reasons. Unfortunately, there is no equivalent of a "locktype" attribute like the "locktitle" available for navtitle, and so our UI is unable to handle both cases at the same time (custom/not set and automatically set).

As the attribute is not a required attribute the XML itself is valid and because not having it does not cause errors with the DITA OT (it may raise a warning but should not raise an error) we changed to not setting it automatically in order meet the previously noted requirements. I'm not sure how serious this is for you; whether you simply wish to have a warning-free DITA OT output log file, or if something in your output process is relying on these values and by itself is unable to process the referenced file to determine the type. If this is causing a real issue in your output it would be great if you could submit an XMetaL Support case so that we can obtain files from you to reproduce the issue and a full description of the implications to better understand why this is a problem.

Unfortunately, at this time there is no way to configure the 7.0 or 8.0 releases to set these values automatically. You will need to use the additional UI provided in the dialog to do that. That means making two additional clicks (over 6.0) when inserting reference. I'm not sure how schwamkrug's macro would need to be modified but in theory that might be doable.

I've put in a request with development to ask if they can add an option to allow you to configure this to be set automatically. That feature will need to be an "all or nothing" setting, since (as noted above) there is no way to programmatically figure out your intention due to the lack of an additional attribute for the type attribute that will let you "lock" it. If you have specific requirements for this feature please contact XMetaL Support directly so they are aware of them. Might as well try to get the feature to cover all client requirements if at all possible, and at the moment we also aren't sure there is a real need.

Note: DITA 1.2 may complicate this further for some people (I see that you are authoring to 1.1). With DITA 1.2, when keys are used (which quite a few of our clients are doing now) you cannot imply the type attribute until build-time (which for most people means when output is generated) so it probably does not make much sense to set the type attribute at all, unless all related keys are referencing the same type of file.
« Last Edit: June 04, 2013, 01:57:07 PM by Derek Read » Logged
Sushimo6
Member

Posts: 2


WWW
« Reply #8 on: September 04, 2013, 03:58:15 AM »

thank you
Logged

[
Pages: 1
Print
Jump to: