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

[Eliot Kimber <ekimber@reallysi.com>]

On 12/17/09 10:39 AM, "Grosso, Paul" <pgrosso@ptc.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.
> 
> No, Eliot, you are wrong.  It most certain can--and, in fact, has to--be
> parsed as XML.  Anything within an element with ANY as a content model
> is XML unless it violates a WFC, and if it violates a WFC, then the
> entire document in which it occurs is not XML.
> 
>> 
>> The <foreign> element itself is of course XML. It's content may or may
>> not be XML.
> 
> Sorry, I'm not going to agree with you on this, Eliot, and I
> believe the mention of non-XML here is confusing and harmful,
> so I'm not going to be happy leaving it in there.

We're talking at two different levels of processing.

For the purposes of processing the document that contains the <foreign>
element, of course its contents are XML in the sense that they are part of
an XML document and will be parsed and communicated to whatever is consuming
the parsed XML document. But that is, as you say, always true and doesn't
need saying. But that's not what I intended to say.

But whole point of <foreign> is that it's non-DITA contents are intended to
be passed to some separate handler that knows how to interpret the content
of the <foreign> element.

That is, a DITA processor will take the content of the <foreign> element and
provide it, in some fashion, to a handler to handle.

The point the spec is trying to make is that what gets handed to the handler
*need not be XML*, meaning that if I take the content of a <foreign>
element, serialize it to a character sequence, and then pass that character
sequence to a handler, that character sequence need not be parsable as XML.

The earlier wording of the spec implied that the content <foreign> was
always XML elements, implying that a handler would always get something
parsable as XML when handled in isolation (e.g., following serialization of
the content of <foreign>). But that clearly cannot be the case.

One challenge here is that the DITA spec cannot specify *how* the content of
<foreign> is provided to a handler, so you have to say something convoluted
to make the point precisely.

Cheers,

Eliot   

-- 
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 610.631.6770
www.reallysi.com
www.rsuitecms.com