Re: [dita] Foreign Generalization: Should be moved to a non-normativeappendix

[Eliot Kimber <ekimber@reallysi.com>]

On 12/1/09 5:43 PM, "Michael Priestley" <mpriestl@ca.ibm.com> wrote:

> Can respecialization be done on the validatable, generalized content
> without knowledge of which system did the generalization? Or does the
> wording below allow different groups to generalize in different ways,
> allowing generalized content to be tied to the source group's
> implementation? 

I don't understand your question.

Generalization is reversible if and only if the class attributes are
preserved. That is independent of how the generalization was created and
whether or not there are foreign elements and whether or not they contain
non-DITA markup. 

I think it must always be the case that for specializations of foreign the
module that defines the specialization must also include the DTD
declarations for any allowed non-DITA content.

Therefore, if you are respecializing to that module, you can integrate the
module into the effective DITA doctype and therefore will have the required
declarations to restore any protected markup as elements of the
respecialized document instance. I don't see how that can depend on the
details of how the generalization was performed.

Here's a question: if <foreign> is not specialized but you have included, in
your shell, declarations for non-DITA elements, the problem still exists
even though foreign itself isn't specialized (and therefore doesn't need to
be generalized).

Therefore, the issue isn't really an issue of generalization, but an issue
of *any transformation* from one DITA document type to a different DITA
document type: there is *always* the potential that non-DITA markup in
<foreign> cannot be validated in the transformation target.

Thus, the focus on generalization with respect to <foreign> is a red
herring, or rather, an instance of a more general problem.

The solution could be made clearer by having a separate "foreign markup
domain" module that provides the declarations for non-DITA elements and is
required to be declared in @domains. That would provide both a DITA-defined
place to declare foreign elements when <foreign> is not specialized and
enable determination if the target doctype supports the same set of modules
[you still wouldn't be able to tell what module a given non-DITA element
type belonged to unless we provided way to define the mapping somewhere].

But without that, you can't know by DITA-defined means that a target
document supports any given non-DITA elements, so your default behavior has
to be to protect such markup.

We should definitely make the isomorphic relationship between content and
<object> within <foreign> clearer in the spec--given an explanation of how
the two are functionally equivalent, it becomes clearer that doing that
transform is one way to solve the unvalidatable foreign content problem.

Note also that in XSLT 2 it is trivial to parse the content of a CDATA
marked section. That was not the case with XSLT 1. Since the Toolkit now
supports XSLT 2 we could, for example, implement the processing of
CDATA-encapsulated <foreign> content in the 1.5 Toolkit.

In fact, now that I think about it, you could even have a complete XML
document with its own DOCTYPE decl in a CDATA marked section, e.g.:

<foreign>
  <![CDATA[
<?xml version="1.0"?>
<!DOCTYPE mathml PUBLIC "whatever" "mathml.dtd">
<mathml>
  ...
</mathml>
]]>
</foreign>

The current standard doesn't disallow that (it couldn't) but it also doesn't
indicate that processors should handle that case as though the content were
a separate document entity. But that behavior is definitely implicit in the
"it can be replaced with an <object> element" statement.

That is, if the content of <foreign> can be replaced by an <object> element
that references the content, it follows that an object element can be
replaced by a foreign element that contains the content referenced by the
<object> element. 

Cheers,

Eliot 

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