Pages: 1
Print
Author Topic: Insertion of @type attributes when loading maps  (Read 3567 times)
schwamkrug
Member

Posts: 33


« on: April 09, 2013, 04:00:50 PM »

Hi all,

This might be an issue with our CMS's integration with XMetaL. I've opened a ticket with them, but I want to check here as well.

When XMetaL (version 6.0) loads a map in the XML view OR in the map editor and you choose to download all referenced files, it is adding @type attributes to all topicrefs.

Before:
<bookmap id="GUID-950D176E-E650-45E2-ACC5-BF75748D3FE1" xml:lang="en-US">
...
<topicref href="GUID-173F9099-3ABF-4448-B30A-F0D3207626AB">
  <topicmeta><navtitle>DAQmx Read</navtitle>
  </topicmeta>
</topicref>

After (immediately after loading in XMetaL):
<bookmap id="GUID-950D176E-E650-45E2-ACC5-BF75748D3FE1" xml:lang="en-US">
...
<topicref href="GUID-173F9099-3ABF-4448-B30A-F0D3207626AB" navtitle="DAQmx Read" type="reference">
  <topicmeta><navtitle>DAQmx Read</navtitle>
  </topicmeta>
</topicref>

That alone wouldn't necessarily be a problem, but for our specialized topic types, it's adding type="reference" instead of type="polyvi" (or whichever other specialized type). This causes problems when publishing these files with the DITA OT, as the type attribute doesn't match the actual type of the topic.

What do we need to configure to ensure the correct value for @type is inserted? Or, maybe even better, how can we prevent those attributes from being inserted at all? They're not necessary for the DITA Open Toolkit, so they seem to just be taking up space.

Thanks!
-Kyle
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2621



WWW
« Reply #1 on: April 09, 2013, 05:03:43 PM »

I'm a little surprised this issue is just coming into play for you. This was a feature included with the XMetaL Author Enterprise 6.0 and earlier  releases that has since been changed. A CMS integration is not needed as the code runs as part of the standard DITA functionality included with the 6.0 release.

To reproduce this with an unmodified (no CMS, no 3rd party code) installation of XMetaL Author Enterprise 6.0 (6.0.1.030 and earlier) all you need do is to open a map containing a <topicref> (that references a DITA topic file using @href) but does not have the @type attribute set. The topic's @type will be set based on an examination of the topic file. For specialized topics the unspecialized topic type will be set.

Once a value has been set I don't believe it will be altered. So if you manually set the values they should remain as you set them. You can do that either using the Attribute Inspector (XML View of Map only) or in the Topic Reference Properties dialog on the "Special Attributes" tab. I've only tried 6.0.1.030 so if you have a different release the behaviour might be different.

There are no patches for this for 6.0 as the behaviour was changed for the 7.0 release, with the same new behaviour also present in 8.0.

We've had the opposite complaint since changing this feature but have yet to decide whether we will implement a user configurable setting to control it. It seems the majority of people prefer their XML to be as "clean" as possible (what we normally strive for). The main reason this feature was implemented for older versions was to be able to show a nice icon next to topicrefs inside the map editor. Those (few people I believe) that want this attribute value set in 7.0 and 8.0 must do so manually.
Logged
schwamkrug
Member

Posts: 33


« Reply #2 on: April 09, 2013, 06:41:53 PM »

For specialized topics the unspecialized topic type will be set.

That's the main issue I'm having. We need to do custom processing of topicref where @type is one of our specialized topic types. It would be nice, but not required, if it wasn't set at all (looking forward to when we can upgrade to 7 or 8, for lots of reasons). But it's critical that it be set to our specialized topic type, if it's set. We're going to have a lot of these, so expecting our authors to set that attribute explicitly won't be sufficient.

I'm comfortable with hacking the macros and javascript you guys provide if you can point me to the right place to look.

Thanks!
-Kyle
Logged
schwamkrug
Member

Posts: 33


« Reply #3 on: April 10, 2013, 08:50:00 AM »

Update: I dug around and found the code that inserts these attributes and managed to override it with a macro in my XMetaL\Author\Startup folder:

Code:
<?xml version="1.0"?>
<!DOCTYPE MACROS SYSTEM "macros.dtd">

<MACROS>

<MACRO name="On_Macro_File_Load" hide="true" lang="JScript"><![CDATA[

  TopicRefObj.prototype.updateMasterDoc = function(doc, node) {
     //Copied from the out-of-the-box implementation. Commented out some calls to XM.XML.SetAttribute();
  }


]]></MACRO>
 

</MACROS>

So, a couple of follow up questions:
- Are there any ramifications to removing @type attribute insertion entirely? I see what I need to change to instead have my specialized topic type inserted. Should I do that instead?
- Are there any issues with my general approach of using a startup macro to override this functionality?
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2621



WWW
« Reply #4 on: April 10, 2013, 12:44:21 PM »

I can't think of any issues this would cause while authoring that are significant. The attribute is not required so XMetaL won't complain. The only functionality that will suffer is that the map editor will not display pretty icons next to topicref elements without this attribute.

I guess the only real decision you need to make is whether your changes to the DITA OT require specific values to be set.

Your macro is probably the best approach. We code the DITA functionality using JScript prototypes to allow for this kind of thing and sometimes issue hotfixes that sort of do what you have done here.
Logged
Pages: 1
Print
Jump to: