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

["Grosso, Paul" <pgrosso@ptc.com>]

Actually, I'm okay with 1, 3, or 4, but 4 is what I was
suggesting on the telcon and would be my preferred path.

---

What are the options with XML Schemas?  

Am I right to think that--as long as the foreign content 
is namespaced--we can get things to work by giving the
foreign element the appropriate content model (i.e., one
that allows any namespaced element)?

---

As far as DTDs, I think we could give the foreign element 
an ANY content model and then all the user would have to 
do is insert declarations such as

<!ELEMENT my:foreign-element ANY>

for each foreign element (without explicitly adding references
to these elements in any content model), and things would work.

That doesn't change your point 1 substantively, but it does
reduce "using you foreign DTD module" to merely adding a
simple declaration for each of your foreign elements making
it much simpler to "share" with others.

paul

> -----Original Message-----
> From: Robert D Anderson [mailto:robander@us.ibm.com] 
> Sent: Tuesday, 2006 October 17 13:16
> To: dita@lists.oasis-open.org
> Subject: RE: [dita] Proposal: Update foreign topic to include 
> processing info for generalization/specialization use case
> 
> 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
>