Duplicate IDs in Table entry

[mjkhan]

We have tag in the DITA Topic configured to generate IDs for id attribute. I insert

tag from Table->Insert Table… menu (lets say 2 rows and 2 columns), populate all the columns (entry tags) and save the document. All the columns (entry tags) now have IDs generated and id attribute is now populated for all columns.

Now I insert 3rd row in the table using Table->Insert Rows or Columns menu. The 3rd row columns have same IDs as the 2nd row columns. This is causing an issue when document is checked into CMS as we have validation in CMS that does not allow duplicate IDs.

The question is why are the tags copy the IDs when new row is inserted in the table? All the other tags (table, p etc.) seem to generate unique IDs when they are inserted into the document.

We are using XMetal 6 SP1 Enterprise for Documentum Webtop.

Thanks
Mahmood

Reply

[Derek Read]

There are a few things going on here all contributing to this issue and I don't think there is an easy solution.

1. The id attribute in DITA, for all elements except (and other DITA root elements), is declared as CDATA in the DITA DTDs (not as ID).
2. XMetaL Author automatically duplicates all attributes from the previous CALS table row's elements when you insert a row (doesn't matter how you insert the row or which DTD is used). This feature is there because that is what works best for most DTDs that implement CALS. When you add a new row you generally expect it to be the same as the previous row and only make changes to those attributes afterwards that need changing.
3. XMetaL Author will actually not duplicate attributes declared as type ID in the DTD (so the document remains valid according to the XML recommendation). Unfortunately #1 above means this check does not apply as these are not true ID attributes.
4. There is no additional code in our DITA authoring solution to intervene and stop #2 from occurring.
5. Your system has a requirement that the element have an @id, and that the value should be unique (not arguing that that doesn't make sense, it is just the final piece that makes this an issue, and one that other clients do not seem to have a need for).

Can you explain why the elements need an @id? What are they being used for? If they are being used to link to portions of a document can you link to a child element inside instead? Or perhaps they are being used to reuse elements (conref)?

This will help me explain the importance of this in order to help development decide where to rank it in our list of things to look at implementing. It may also help understand how it should be implemented in case you have additional requirements not described already.

Reply

[Author]

Posts