RE: [dita] Foreign Generalization: Should be moved to a non-normative appendix

["Bruce Nevin (bnevin)" <bnevin@cisco.com>]

To do what you want, escaping would need a scoping mechanism (like
nested parens) or something analogous to the trace that is constructed
in the value of the class attribute. 

> -----Original Message-----
> From: Eliot Kimber [mailto:ekimber@reallysi.com] 
> Sent: Wednesday, December 02, 2009 5:36 PM
> To: Grosso, Paul; dita
> Subject: Re: [dita] Foreign Generalization: Should be moved 
> to a non-normative appendix
> 
> Hmm, you're right. So I was right all along.
> 
> Hmph and hmph again.
> 
> However, in thinking about this in some detail, I've come to 
> the conclusion that there's no reliable way to manage escaped 
> foreign content through multiple sequences of transform.
> 
> In particular, if we said that DITA-to-DITA transforms must 
> *always* escape content and respecialization transforms 
> unescape it one level, that will work if the output of the 
> transform is *always* the input to a respecialization. But 
> what if it's the input to a transform that does something 
> other than respecialization, either type-to-type 
> transformation or partial generalization?
> 
> In that case, it's impossible for a transform to know how 
> many levels of escaping have been applied relative to the 
> original topic. And it doesn't work to say that all 
> transforms must unescape and then re-escape because that only 
> works if they are not the first in a sequence of such 
> transforms and there's no way to know if you are the first 
> transform in a sequence.
> 
> For example, say I start with a topic of Type A and I 
> transform it to a topic of Type B, escaping all <foreign> 
> content. I then transform the topic of Type B to a generic 
> topic, again escaping all of the <foreign> content.
> At this point the <foreign> content is doubly escaped, not 
> what I wanted. I then respecialize the generic topic back to 
> a topic of Type B. I blindly unescape the content but it's 
> still escaped one level. In this scenario, there is no way 
> for a given transform to know how many levels of escaping 
> have been applied.
> 
> So this suggests that escaping is not a viable option, which 
> brings us back to side files being the only reliable option 
> for handling <foreign> content through DITA-to-DITA transformations.
> 
> Cheers,
> 
> Eliot
> 
> On 12/2/09 3:24 PM, "Grosso, Paul" <pgrosso@ptc.com> wrote:
> 
> > 
> > 
> >> -----Original Message-----
> >> From: Eliot Kimber [mailto:ekimber@reallysi.com]
> >> Sent: Wednesday, 2009 December 02 15:19
> >> To: Michael Priestley
> >> Cc: dita; Grosso, Paul
> >> Subject: Re: [dita] Foreign Generalization: Should be 
> moved to a non- 
> >> normative appendix
> > 
> > . . .
> > 
> >> Also, I was mistaken in my assertion that <foreign> can contain 
> >> untagged text content--it can't (I had forgotten that ANY content 
> >> models are still element only). So even if you have a data format 
> >> that is not itself XML, you'd still have to define a new 
> element type 
> >> to hold it.
> > 
> > That's incorrect.  Quoting point 4 of the "element valid" VC in XML 
> > (at http://www.w3.org/TR/REC-xml/#elementvalid):
> > 
> > The declaration matches ANY, and the content (after replacing any 
> > entity references with their replacement text) consists of 
> character 
> > data, CDATA sections, comments, PIs  and child elements whose types 
> > have been declared.
> > 
> > paul
> > 
> > 
> ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the 
> OASIS TC that 
> > generates this mail.  Follow this link to all your TCs in OASIS at:
> > 
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> > 
> 
> --
> Eliot Kimber
> Senior Solutions Architect
> "Bringing Strategy, Content, and Technology Together"
> Main: 610.631.6770
> www.reallysi.com
> www.rsuitecms.com
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
> oups.php 
> 
>