Reply To: Duplicate IDs in Table entry

[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