[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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. 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]