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

["Gershon Joseph (gerjosep)" <gerjosep@cisco.com>]

Did we come to closure on this one? I guess we may have to pick it up in
the new year. However, I wanted to clarify my own thinking here: My
understanding is <foreign> may contain some "non-XML" form of markup,
such as RTF (Rich Text Format) or TROFF. If we limit <foreign> to
contain only XML content, then we have no way of including non-XML
content in DITA files. I think the intent here is to support the
inclusion of such "code" in the DITA content. Of course, this content is
valid XML in the sense that whatever is contained in the <foreign>
element is CDATA. Any special XML character (such as <) would obviously
be replaced by its Unicode character or text entity to prevent it from
breaking the XML parser -- presumably such characters would be converted
to their text character equivalents when generalized out into a separate
file. I assume this is all obvious to the implementer, but wonder
whether we should say something about it anyway to be on the safe
side...


--
Gershon

-----Original Message-----
From: Grosso, Paul [mailto:pgrosso@ptc.com] 
Sent: Thursday, December 17, 2009 6:42 PM
To: dita
Subject: RE: [dita] foreign element description issue (non-XML?)

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


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