DITA Processing Model

From: Michael Priestley [mailto:mpriestl@ca.ibm.com]
Sent: Tuesday, October 11, 2005 3:36 AM
To: Paul Prescod
Cc: dita@lists.oasis-open.org
Subject: Re: [dita] Repeated conrefs

Comments below...

Michael Priestley
IBM DITA Architect
SWG Classification Schema PDT Lead
mpriestl@ca.ibm.com

"Paul Prescod" <paul.prescod@blastradius.com> wrote on 10/06/2005 07:50:36 AM: > By definition, every element that is conrefed has an “id” attribute. > Is it therefore invalid to conref the same element into the same > topic twice?

It is still valid. The id on most elements is not constrained to be unique, precisely to allow this as a valid case.

[ PAUL PRESCOD] I do not agree that the id on most elements is not constrained to be unique. As I understand it, the id on every elements is constrained to be unique WITHIN SOME CONTEXT. If you conref a topic into the same file twice then you will run into a per-file uniqueness problem. If you conref a paragraph into a topic twice then you will run into a per-topic uniqueness problem.

>And to conref the same topic into a parent topic twice?

This is not so valid. Topic-level elements must have unique ids. If the same topic gets conref'd into a document in multiple places, this does produce an error once the resolved document is parsed, and the conref processor doesn't currently check for that.

[ PAUL PRESCOD ] What in the DITA specification would lead me to understand that this is not valid? Obviously having two topics with the same ID is not possible in a DITA input file. But it isn't clear to me what constraints there are on the post-CONREF output. It isn't even clear to me whether the post-CONREF output is supposed to be uniformally DITA compliant. Similar questions apply to the post-FILTERING output, the post-GENERALIZATION output and the post-MAP-combination output.The questions are compounded when you combine these transformations.

SGML, XML 1.0 and the XML Family have had similar specifications problem and the answers to these questions were only ever answered by picking the brains of the architects (which, in the case of the XML family of standards was almost impossible because the architects for different specs did not necessarily communicate). Having been through that process three times, I'd rather get the answers into the DITA spec while we still have time before we are mobbed with hundreds of implementors who are not content to just copy the DITA Toolkit. In particular, I am proposing a formal DITA processing model as per the XML processing model proposed here:

"The original motivation for defining a processing model was to normalize the application of W3C-defined mechanisms; it is a very different thing to apply XSLT and then XInclude, as opposed to XInclude and then XSLT."

Similarly, it is a very different thing to filter before conref than to conref before filter . For example, if you filter before conref, then a conref to a filtered element is a broken link. But if you conref before generalizing then there is an intermediate state where a topic may have elements within it that are not allowed by its content model. So DITA should either specify the order of these things (hard-coded) or provide a way for DITA users to specify the order (some kind of pipelining language).

>
> Is it legal for an element with a DITA conref to reference another > element with a conref? If so, shouldn’t DITA disallow mutually > recursive conrefs?

It should, it's just an edge case that is expensive to check for, so I don't know of any process that currently does.

Okay, so we agree that the specification should change in this way. Is there a tool we should use to keep track of this agreement? i.e. an issue tracking system?

dita message