[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
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]