[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Proposal: Update foreign topic to include processing info for generalization/specialization use case
Robert, I haven't had time to think about this in detail, but it might be worth pursuing. It sounds better than sticking markup in PIs. I haven't decided if there are other problems with this suggestion yet or not. paul > -----Original Message----- > From: Robert D Anderson [mailto:robander@us.ibm.com] > Sent: Monday, 2006 October 23 10:36 > To: dita@lists.oasis-open.org > Subject: RE: [dita] Proposal: Update foreign topic to include > processing info for generalization/specialization use case > > Thanks, Paul. > > I do have one other thought on this -- rather than trying to > hide foreign > content during generalization, what if we export it -- > essentially, turn it > into an imbedded object? Others have pointed out that foreign > content is > really an inline object, so this seems to make sense > architecturally. We > could pretty easily turn this: > <math class="+ topic/foreign mathml/math "> > mathml content here > </math> > > into > <foreign class="+ topic/foreign mathml/math "> > <object data="imbed1.xml" type="DITA-foreign"/> > </foreign> > > Some additional details on this: > * The object element may already be used for alternate > content. That would > not be exported - so you end up with one object pointing to > the foreign > content (type="DITA-foreign" or some equivalent), and one > object with the > alternate content. > * Foreign content may use several main elements -- such as > <foreign><this/><that/></foreign> -- so the exported file > should have a > root <foreign> element to remain valid. > > I think the basic approach of exporting the info and using > <object> is a > lot more elegant than processing instructions, both from a > DITA perspective > and from a general XML perspective. It allows me to edit my > topics with > mathml, and then generalize and send them to somebody without > mathml for > further editing/processing. It also doesn't use any kludges > to hide XML as > if it was not XML. > > Does this seem like an approach worth pursuing? > > 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/18/2006 08:45:31 AM: > > > 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 > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]