[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] foreign element description issue (non-XML?)
Following
some off-list discussion between Kris, Gershon, Paul, and me here is another
suggestion: The <foreign> element allows the
introduction of non-DITA content, for example, MathML, SVG, or Rich Text Format
(RTF). The <foreign> element or a specialization may contain more than
one type of non-DITA content or a mix of DITA and non-DITA content.
Specialization of the <foreign> element generally is implemented as a
domain, but architects looking for more control over the content may implement
foreign vocabularies as structural specializations. This
wording is similar to the suggested wording that Kris proposed a few days ago,
but it is less directive in terms of processing. With the previous proposed
wording I worried that we were placing new requirements on processors that will
be difficult or impossible to implement for all of the possible non-DITA
content that might be included within the <foreign> element or a
specialization. Whatever
wording we finally agree on is intended to replace the current (and much more
detailed) wording in the draft 1.2 spec. Here
in reverse order are the various suggestions that we’ve been working our
way through to get to this point: Kris’s
proposal from 28 December: The <foreign> element allows the
introduction of non-DITA content, for example, MathML, SVG, or Rich Text Format
(RTF). If the <foreign> element contains more than one type of non-DITA
content, processors /should/ render all the content types. Specialization of
the <foreign> element generally is implemented as a domain, but
architects looking for more control over the content can implement foreign
vocabularies as structural specializations. Paul’s
suggested wording from 17 December: 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. From the 3rd
review draft of the DITA 1.2 Language Reference section on the <foreign>
element under Specialization elements
(this is the material that would be replaced):
The default
behavior for <foreign> is to try to display the content. If the processor
cannot render the content, it may emit a warning. Base
processing attempts to display <foreign> content unless otherwise
instructed. The enabler
of the foreign vocabulary must provide the processing and override the base
processing for <foreign>.
From
the DITA 1.1 Language Reference section on the <foreign> element in the
chapter on Miscellaneous elements:
-Jeff > -----Original Message----- > From: Kristen James Eberlein
[mailto:kris@eberleinconsulting.com] > Sent: Monday, December 28, 2009 10:40 AM > To: dita > Subject: Re: [dita] foreign element description
issue (non-XML?) > > How about the following wording: > > The <foreign> element allows the introduction
of non-DITA content, for > example, MathML, SVG, or Rich Text Format (RTF). If
the <foreign> > element contains more than one type of non-DITA
content, processors > /should/ render all the content types. Specialization
of the <foreign> > element generally is implemented as a domain, but
architects looking > for more control over the content can implement
foreign vocabularies as > structural specializations. > > Kris > > Grosso, Paul wrote: > > See my suggested wording at the bottom of this
email. > > > > <snipped> > <kje>a lot of content snipped</kje> > > > >> > >> 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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]