RE: [dita] Proposal: Update foreign topic to include processing info forgeneralization/specialization use case

[Robert D Anderson <robander@us.ibm.com>]

It seems like - if we support the foreign and unknown element - we have
these options when using DTDs:

1. We state that, if you use the foreign or unknown elements, you have no
way to share topics with others that do not use your foreign DTD module.
This would be the only way to make a DITA document that cannot be taken
back to the topic type that represents a least-common-denominator, because
you can never share with somebody that does not use this module.

2. We define some way to hide the information when generalizing. Groups can
go back to the most common form; if the common form does not use the
foreign specialization, then they use the alternate content they (may have)
defined with <desc>. So far the only real proposal for hiding the
information is with a PI, which has already been declared a kludge.

3. We state that foreign content is simply discarded during generalization
- you can't bring it back if you're going to a format that doesn't support
it.

4. . We leave it up to each implementation. This means that if you
generalize with one program, other programs may not be able to bring it
back. Currently the spec defines how to generalize, which means that all
implementations should be able to work with specialized/generalized content
in the same way.

Does anybody see any other options? Paul, it sounds like you're suggesting
option one -- does that sound right?

Thanks-

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit
(507) 253-8787, T/L 553-8787

"Grosso, Paul" <pgrosso@ptc.com> wrote on 10/17/2006 11:48:36 AM:

>
> > -----Original Message-----
> > From: Eric Sirois [mailto:esirois@ca.ibm.com]
> > Sent: Tuesday, 2006 October 17 09:32
> > To: dita@lists.oasis-open.org
> > Subject: [dita] Proposal: Update foreign topic to include
> > processing info for generalization/specialization use case
> >
> > The foreign content proposal (#35) for incorporating foreign
> > content in
> > DITA did not have a use case that covered what would
> > happen when an DITA document contain foreign content are
> > generalized the
> > content is not longer valid, when using DTDs for
> > validation, because the base DTD does not include the foreign
> > vocabularies.
>
> When using DTDs, if it is desired for the generalized
> content to be DTD-valid, then the foreign content elements
> should be added to the DTD.
>
> > I propose that we hide the foreign content via a processing
> > instruction in
> > the generalized document. It gets us past the validator
> > issue. The content could then be re-instated during the specialization
> > process.  Hiding in a comment was discussed, but there
> > is no guarantee that tools keep comments in the documents.
> > Also, it makes
> > reinstating the foreign content during specialization
> > much more difficult.
>
> Putting what should be markup as characters in either a
> comment or processing instruction (PI) is quite distasteful
> to me.
>
> Also, many tools toss PIs too--not ours unless such is
> explicitly requested, but others do.
>
> Note, your generalization process will need to get tricky
> if the content you are trying to hide in a PI contains
> a "?>" string.
>
> Finally, this all sounds too kludgy and implementation based
> to me for a specification.
>
> >
> > In the case where <foreign> contains an <image>, <object>, or
> > <desc>, they
> > should not be hidden within the processing instruction.
> > All content within <unknown> will be hidden in a processing
> > instruction.
>
> paul