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-normative appendix

I'd like to suggest we do just this -- move the detailed process to an
appendix and leave only the base info (if we actually have anything
normative to say here!) in this topic, and then just refer to the
appendix as one possible approach. I don't think we need to discuss this
at the TC unless someone feels we need to.

Personally I think we should treat this as an editorial note and let
Eliot add the 1.3 feature to the Wiki page.


-----Original Message-----
From: Eliot Kimber [mailto:ekimber@reallysi.com] 
Sent: Tuesday, December 01, 2009 6:28 AM
To: dita
Subject: [dita] 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

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

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.



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

To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:

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