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: Foreign Generalization: Should be moved to a non-normative appendix


The 1.1 spec and the 2nd review draft of the 1.2 spec include the topic
"Foreign generalization", which defines a specific set of rules for how to
handle the content of <foreign> elements during a generalization process.

Paul Gross logged the comment:

The discussion (preceding the examples) in "Foreign generalization" is too
prescriptive for a standard. It gets right down to describing specific
processing and even the file name to use. This needs to be rewritten to
describe intent, not a detailed implementation of that intent.

I agree with Paul: this topic is defining implementation details that are
not appropriate as normative requirements.

The process outlined in the current topic is a potentially useful
implementation choice for handing foreign elements in a way that ensures
they won't interfere with the validation of generalized documents, but since
not all generalization processes need result in literal document instances
nor would such instances necessarily be validated, it's clearly not
appropriate as a normative requirement.

I think the appropriate thing to do with this topic is to move it to a
non-normative appendix and present it as one way of managing the processing
of generalized documents with foreign content.

Note that the only actual potential problem is validation of generalized
result documents when the DTD or schema used for the generalized instance is
either synthesized dynamically or invariant and not defined by somebody
familiar with the documents being generalized.

That is, there is no problem in generalizing specializations of <foreign>
themselves, nor is there a problem generalizing any XML content they have,
since generalization of the content isn't relevant (because it's not DITA,
by definition). The only practical problem is validation of the generalized
result when two things are true:

1. You want to validate the generalized documents
2. You haven't pre-defined their shells to include the DTD or XSD components
needed to validate the XML content of <foreign> elements.

This can really only be the case when you are doing generalization to
<topic> using the TC-provided shell (or, more likely, a shell that includes
no domains).

If you are controlling precisely what the generalization targets are then
you very likely know enough about the documents involved to have pre-created
a generalization shell that can provide for the validation of XML content of
<foreign> elements.

It also occurs to me that if we had another vocabulary module type, "foreign
vocabularies", there would be no problem because the @domains attribute
would provide enough information to synthesize a shell that included the
necessary foreign element validation components. I will propose just this
for 1.3.

Cheers,

Eliot 

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



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