Reply To: Save As and Topic ID

[Derek Read]

I think the simplest thing to do might be to create an application-level macro that deletes the id attribute from the root element. The next time the document is opened a new value should be inserted (provided you have the option for “Auto-assign element IDs” checked in Tools > DITA Options). Or, if you make a few more changes and then save the id attribute will also be inserted at that time as well. Or, if you want to add additional logic to set the id at the same time it is being removed you could try to do it here as well, either after or instead of the removal (probably using the DOM API setAttribute() instead).

Example:
[code]

![CDATA[
ActiveDocument.documentElement.removeAttribute(“id”);
]]>

[/code]

I can't say if this will continue to work in the future because the DITA functionality is considered a closed system, however, this should probably work for current releases. It functions as I expected with 5.1.

Test this thoroughly before actually using it in production.

To make this an application level macro you will need to place this inside a file with an MCR extension in the Startup folder. I recommend this because the code is then separated from the code we ship, making it “cleaner” (rather than modifying files we ship).

Your second question seems to be asking if XMetaL Author Enterprise itself (or perhaps the DITA OT) cares about the text casing of the id attribute value. They do not.

Note that id is defined as NMTOKEN in the DTDs. It is that definition that XMetaL Author Enterprise uses for validation. Our philosophy is not to guess at anything else beyond what is defined in the DTD (customizers of other DTDs and Schema may choose to add additional business logic but we have avoided this for DITA). See: [url=http://www.w3.org/TR/REC-xml/#NT-Nmtoken]W3C XML NMTOKEN definition[/url]. So strictly from an XML validation point of view most of Unicode is allowed in there.

However, the DITA spec uses URI for linking and so that comes into play when building id values (specific characters you should not use such as # despite them being technically “valid” for XML on its own) and it is probably safest (and simplest) to stick with [a-z][A-Z][0-9] and perhaps characters such as hyphen and underscore if you opt to change the behavior or manually edit an id value. The default behavior uses UUID-like (aka: GUID) values because in the beginning it was not entirely clear if we needed to worry about them being unique (primarily for the DITA OT), so we chose to play it safe. Some other tools might care, though I don't know of any.

Reply