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

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

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.

More below.


> -----Original Message-----
> From: Gershon Joseph (gerjosep) [mailto:gerjosep@cisco.com]
> Sent: Sunday, 2009 December 27 11:45
> To: Grosso, Paul; dita
> Subject: RE: [dita] foreign element description issue (non-XML?)
> 
> 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.

Your last sentence above either is tautological or makes no sense
depending on what you mean by "non-XML" which is the entire point
of this discussion.  

> I think the intent here is to support the
> inclusion of such "code" in the DITA content. 

Yes, agreed.

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

My fear is that nothing is "of course" or "obvious."  

Furthermore, I claim that that XML spec makes it clear what XML 
is and what, by extension, "non-XML" is, so the DITA spec cannot
redefine what "non-XML" means, and therefore we cannot use the
term "non-XML" in the DITA spec to describe the content of an 
element in an XML document.

I suggested some replacement wording that I think is reasonable.  
I'd be happy with other replacement wording--including some that
mentions, as examples, rtf or troff--as long as we don't use the
term "non-XML".

paul

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