Profile

My understanding is that ditabase allows all topics defined within the technicalContent package, plus the generic topic from base, to be aggregated into a single XML instance. Since the technicalContent package has constrained the shell DTD for task (task.dtd), then the shell DTD for ditabase ought to ...

One way to approach this issue is to assume that the semantics are simpler in task and in concept than they are in syntax diagram. In the context of syntax diagram, the semantic goal is to delineate the rules for command usage. In the context of task, the semantic goal is to direct the reader use ...

I do not agree that there is an advantage of using steps-informal instead of steps when the semantics of steps works. Here is why: The steps element is semantically more specific than the ol element. Semantically specific markup increases intelligence that is embedded in the markup. Increased intelligence ...

I have a related use-case. I just finished porting an unstructured FrameMaker publication to DITA, and found that I had to fabricate several title-only topics to furnish xref targets. When it came time to integrate the HTML into the product's help system, I had to fabricate several more such topics to ...

Hello, We ought not specify how the element gets rendered; however, we ought to declare a processing expectation. As Eliot pointed out, establishing a processing expectation for 'ol' sets a precedent for doing this sort of thing. Moreover, several aspects of the CALS table model would not be admissible ...