Home Forums DITA and XMetaL Discussion 5.1: Why Can Some Nested Required Elements be Deleted? Reply To: 5.1: Why Can Some Nested Required Elements be Deleted?

Derek Read

Reply to: 5.1: Why Can Some Nested Required Elements be Deleted?

I'm assuming you have created a specialized DITA DTD, but that seems to be beside the point. I will concentrate on your main complaint which is that the product is letting you remove required elements.

This is expected behavior. See the topic in XMetaL Author's help called 'Validation and rules checking'. There are subtle differences between the two functions, with the main points being:

Validation checks to see if the markup is correct and complete with reference to your DTD or Schema. Rules checking ensures that you do not break the required structure as you edit your document by allowing you to insert only valid elements.

Validation occurs automatically when you save your document or when you switch from Plain Text view to Normal or Tags On view.

Rules checking is less stringent than validation in that it checks that no errors have been made, but does not check that the markup is complete.

XMetaL Author will allow you to delete markup that is required, starting from the bottom up (end of document back toward the beginning) because in many cases it is possible to have what amounts to a “branch” in a DTD or Schema.

The functionality that controls element insertion is the “Rules checking” feature. Unless additional business logic making parts of a document non-removable has been coded (which is not something we can do for DITA, because different clients have different needs) it will always be possible to keep deleting parts of a document until there is nothing left. This allows an author to back up if necessary.

One simple example with a DTD containing this definition . If you have the XML XMetaL will not allow you to remove until you remove . However, you can also remove all of at any time in this case, and you can remove after you remove .

Another example, for a DTD where a child element must be followed by one of two of its siblings, like so: .
In this case MUST be followed by one of either or . If you insert and then later you decide you actually wanted instead, XMetaL allows you to remove so you can insert .

A more extreme example (which applies for all DTDs) is that if you decided you do not wish to use as your root element (same DTD as above) but instead restart this document using , or . XMetaL allows you to back up to the point where your document is empty and do that. So, the simplest case: press Ctrl+A then delete (in any document). In this case the Element List shows all elements defined in the document because any of them are allowed to be the root (see XML Recommendation). I would call the resulting document (one that starts with an element not typically considered the “root” element) a “partial document”. Such a document is typically included inside another larger “main” document at some point (often during post processing or a transformation of some kind). Of course, once you pick a root element and insert it, Rules Checking kicks in and the Element List contracts to show a smaller list of allowed elements.

Hope this makes sense and that I have not confused things further with too many examples.

Unfortunately, this means you may need to train some users if they are working with complex content (and in your case you have modified the DTD so you possibly cannot just refer them to the DITA Language Spec but might need some additional docs of your own creation). However, we provide two tools that may help in addition to the Validation Log:
1. The Element List. This window shows only those elements valid at a particular location (current position) in the current document. When one of the elements is required, and that required element is the only possible required element, it is listed in bold.
2. The Alt+F1 help feature (specifically for our standard DITA customization only) that opens the 'DITA Language Specification' to the definition for the current element. This includes a description of the intended usage, a listing of parent elements the element may appear in, child elements allowed and attributes.