OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [dita] DITA Processing Model

Hi Paul,

Responding specifically to the processing order, the current order in the
toolkit was reached based on a lot of trial and error with IBM documents.
At this point, a lot of those documents depend on the current order, so if
we are going to formalize on a processing order I'd certainly be interested
in keeping the one we have now. On the other hand, I have no objection to
letting users adjust the processing order. It does mean two users may get
different results with the same files, but that is the case with any system
where one user adjusts the pipeline to make their files work differently.

If you'd like more information on why each item runs in the current order,
I'm happy to give details, but I won't have time to do so for a couple of

For IDs - my understanding is that non-topic IDs are supposed to be unique
within a topic. The DITA toolkit's processing pipeline operates under this
assumption. I believe it generates some warning messages for duplicate IDs
within a topic, although today you need to scan through the console log to
find them.

In terms of keeping intermediate files DITA-compliant, we have tried to do
so as much as possible, though I do not think it is required. To that end,
one of the things we do is adjust IDs that are pulled in by conref, so that
they do not conflict with IDs in the current topic. This is important for
later steps that retrieve cross reference text, and might otherwise have to
choose between multiple copies of the same ID. For example, you may have a
cross reference to a table with id="info". If you use conref to pull in a
paragraph or a list item with id="info", then your cross reference of
"#topic/info" will actually be pointing to both.

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit

             "Paul Prescod"                                                
             stradius.com>                                              To 
                                       "Michael Priestley"                 
             10/21/2005 01:18          <mpriestl@ca.ibm.com>               
             PM                                                         cc 
                                       [dita] 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

 "Paul Prescod" <paul.prescod@blastradius.com> wrote on 10/06/2005 07:50:36

 > 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


 And I am proposing it for the same basic reasons:

 "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

 > 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?

  Paul Prescod

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]