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

I'm a little concerned about this -
adding foreign to 1.1 was a big deal, and part of the compromise that allowed
its addition was support for mechanisms that allow exactly the kind of
blind generalization up to topic that all other sorts of specialization
allow.

If we need to rewrite the section to
make it less file-system-specific, that's fine. But all sections on generalization
have been normative in the past, regardless of element. If we take one
piece of the generalization mechanism and make it non-normative, then we're
pretty much giving up on blind generalization. That's been a basic feature
of the architecture up till now.

Michael Priestley, Senior Technical
Staff Member (STSM)

Lead IBM DITA Architect 



http://dita.xml.org/blog/25

From:
"Gershon Joseph (gerjosep)"
<>

To:
"Eliot Kimber" <>,
"dita" <>

Date:
12/01/2009 09:40 AM

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.

--

Gershon

-----Original Message-----

From: Eliot Kimber [mailto:]

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

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

---------------------------------------------------------------------

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:

https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

---------------------------------------------------------------------

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:

https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php