RE: Comments on the Generalization section

Thanks Kris for pulling this out.

Adding some missing information and correcting a typo in one of my comments. I updated the table below.

Unlock the Knowledge in Your Enterprise™

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Please notify us by return email if you have received this email in error. © 2022, Precision Content Authoring Solutions Inc. Toronto, Ontario, Canada

gershon joseph
senior information architect

From: kris eberleinconsulting.com <kris@eberleinconsulting.com>
Sent: Tuesday, September 6, 2022 1:08 PM
To: Gershon Joseph <gershon@precisioncontent.com>; dita <dita@lists.oasis-open.org>
Subject: RE: Comments on the Generalization section

OK, I went through Gershon’s PDF and extracted his comments. Below is a summary:

Topic	Comments	Notes
8.4.1 Overview of generalization	Why is this paragraph not a normative rule while the next one is? Surely both should either be normative rules or neither should be normative rules?
8.4.2 Element generalization	Do we care whether they do this or use some other method to generalize? I suspect this is part of the processing stuff we are trying to remove in 2.0, right? I think we can rewrite this without making it a process, but explaining how the element names would change.
8.4.2 Element generalization	rework this paragraph to make it clearer. It seems to assume mostly that there in is only a single specialization. We should make it more easily understood when more than two levels of specialization are involved.
8.4.3 Processor expectations when generalizing elements	Remove this topic from the spec.
8.4.3, normative rule 066 (410)	Rework this requirement into the generalization topic after the paragraphs or rules that talk about the @class attribute values.
8.4.4 Attribute generalization	This indeed seems to be spec material. Interesting. Need to figure out where to put this in the new generalization topic. Hopefully once we rework the element generalization topic this attribute generalization will fit. Re the example: Why give an example that's wrong? If this example has any value, then introduce it as an error condition that should be avoided.
8.4.5 Generalization with cross-specialization dependencies	In the third paragraph, “However, codeConcept<> could be generalized to concept or topic…” my comment was to change “codeConcept<>” to “<codeConcept>”.

Best,

Kris

Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Owner, Eberlein Consulting LLC
kris@eberleinconsulting.com

Skype: kriseberlein; voice: +1 (919) 622-1501

From: dita@lists.oasis-open.org <dita@lists.oasis-open.org> On Behalf Of Gershon Joseph
Sent: Sunday, September 4, 2022 10:47 AM
To: dita <dita@lists.oasis-open.org>
Subject: [dita] Comments on the Generalization section

Hi all,

I have removed all section except for the Generalization section from the attached PDF. Please review my comments and edits. Kris will put this on the agenda of an upcoming meeting to discuss what to do with the Generalization content.

Cheers,

Gershon

Unlock the Knowledge in Your Enterprise™

gershon joseph senior information architect
180 John St. Toronto, ON Canada M5T 1X5 T: (647) 557-5965 gershon@precisioncontent.com
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Please notify us by return email if you have received this email in error. ©2022, Precision Content, Toronto, Ontario, Canada

dita message