RE: [dita] foreign element description issue (non-XML?)

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

Sorry, our last couple messages cross in the ether.

> -----Original Message-----
> From: Eliot Kimber [mailto:ekimber@reallysi.com]
> Sent: Thursday, 2009 December 17 10:39
> To: Grosso, Paul; dita
> Subject: Re: [dita] foreign element description issue (non-XML?)
> 
> On 12/17/09 10:29 AM, "Eliot Kimber" <ekimber@reallysi.com> wrote:
> 
> > But the *content* of the <foreign> element is not XML, meaning that
> it
> > cannot, itself, be parsed as XML, which is the intended meaning of
> the
> > statement you cite.
> >
> > The <foreign> element itself is of course XML. It's content may or
> may not
> > be XML.
> 
> It's actually more complicated than the current spec maybe suggests,
in
> that
> the content of the <foreign> element may be a mix of DITA and non-DITA
> elements as well as character data, where the DITA elements are
> interpreted
> according to their normal DITA semantics (e.g., <desc>) but everything
> else
> is interpreted according to whatever semantics are imposed by the
> specialization of <foreign>.
> 
> Not sure how to say that clearly or crisply.
> 
> In particular, processors that pass the content of foreign elements to
> handlers cannot simply pass a sequence of elements but must provide
all
> nodes that make up the content of the <foreign> element.

I don't see why you have to get into this level of detail at all.

What I've suggested for a replacement for this paragraph
(fixing some other wording problems) is:

The <foreign> element allows the introduction of non-DITA content such
as MathML, SVG, or some textual data format. If <foreign> contains more
than one alternative content element, they should all be processed.
Specialization of <foreign> should be implemented as a domain, but
architects looking for more control over the content may implement
foreign vocabularies as structural specializations. 

paul