MHonArc v2.5.0b2 -->
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
days.
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"
<paul.prescod@bla
stradius.com> To
"Michael Priestley"
10/21/2005 01:18 <mpriestl@ca.ibm.com>
PM cc
<dita@lists.oasis-open.org>
Subject
[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
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:
http://www.mnot.net/papers/XMLProcessingWS.html
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
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?
Paul Prescod
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]