On 12/27/09 12:07 PM, "Grosso, Paul" <> wrote:
> See my suggested wording at the bottom of this email.
>
> I suggest that as the resolution.
>
> Note, no where does my wording suggest that the content of
> the foreign element is restricted in such a fashion that
> would prohibit rtf or troff or what have you. On the other
> hand, no where does it suggest that the content of the
> foreign element no longer has to be well-formed xml which
> is what the "non-XML" wording more than implies, that's
> in fact what it says outright and which is wrong.
I am generally happy with Paul's suggested working, quoted here:
> 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.
>
I'd have to review this in the context of the larger topic to make sure
there isn't some subtlety, but I think it captures the intent of indicating
that textual (non-markup) content is allowed and meaningful without using
the term "non-XML".
Cheers,
E.
--
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 610.631.6770
www.reallysi.com
www.rsuitecms.com
