OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

Eliot Kimber <ekimber@reallysi.com> wrote on 12/01/2009 10:57:48 PM:
> > 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.

One of the possible outcomes of generalization is validatable DITA, with a doctype and preserved class attributes that allow reversion to the previous doctype. This is per the existing generalization spec. I want to understand whether this scenario is still supported if we don't say how to generalize foreign content.

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

If generalizers are not required to split out foreign markup from the document when creating a validatable generalization, then they may use some other technique, for example namespaces, which could work for them if they're using schemas but will break if the recipient is using DTDs.

If generalizers do split out the content, but choose not to set the DITA-foreign type on the object element, then a respecializing process will not be able to distinguish which objects should be resolved to inline during respecialization.

The guideline for naming conventions on the generated sidefile were intended to limit the possibility of a generated file overwriting another existing file, and to make it easy to associate the generated file with the source file and topic from which it was extracted. This part is already just a recommendation.

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

What you describe is a non-standard use of <foreign>. If someone does this, then they've no longer got valid DITA content according to the spec.

The intent of <foreign> specializations is to provide a hook and name for the module, which can then provide a specific content model. The foreign markup can then be included and assembled into a doctype like any other domain module. The specialized <foreign> element provides a signal to processors about where that foreign markup has been included (through the specialized element's class attribute).

If you include random markup in your DITA document without a specialized element, then there is no way for a processor to tell whether a specific document contains markup from that domain. That means it cannot be reliably generalized to any valid ancestor.

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

What you're suggesting is already part of the spec, and is already required. This is how <foreign> is meant to be used. And you would be able to tell what module a non-DITA element type belonged to, by inspecting the class attribute of its specialized container.

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

Without that you don't have valid DITA, according to the spec. So you are protecting a broad range of behavior that is already disallowed. We don't allow people to randomly add markup to DITA and still call it DITA. There are procedures, to ensure interoperability and interchangeability. Specializing <foreign> is one of those procedures.

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

I'm not going to worry about this for 1.2. I just want to protect the behavior we defined as valid for 1.1.

> Cheers,
> Eliot
> --
> Eliot Kimber
> Senior Solutions Architect
> "Bringing Strategy, Content, and Technology Together"
> Main: 610.631.6770

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]