dita — archive

Re: Early feedback on Issue 670, Impose Role

From: Eliot Kimber <[email protected]>
To: [email protected]
Date: Mon, 27 Jun 2022 14:41:00 -0000

I’m generally happy with the proposal with two comments: I think “impose” might be the clearer value to mean “impose the role”, i.e. imposerole=”impose”/imposerole=”keeptarget” or even “impose/noimpose” to be more consistent but less grammatical. Need to clearly stipulate the implications for multiple levels of indirection: does the explicit or implicit @imposerole value on the initial keyreffing topicref apply to the ultimate target? I think that’s the intent but that’s not quite what the current draft says. I agree with Gershon that “impose-role” might be an easier-to-read attribute name. I don’t remember if we have any general attribute naming principle that prefers or avoids dashes as word separators. I also can’t think of a better name for the attribute itself. I think “impose role” is a clear _expression_ of the semantic. Cheers, E. _____________________________________________ Eliot Kimber Sr Staff Content Engineer O: 512 554 9368 M: 512 554 9368 servicenow.com LinkedIn Twitter YouTube Facebook From: [email protected] <[email protected]> on behalf of Gershon Joseph <[email protected]> Date: Sunday, June 26, 2022 at 9:32 AM To: Robert Anderson <[email protected]>, [email protected] <[email protected]> Subject: [dita] RE: Early feedback on Issue 670, Impose Role [External Email] Hi Robert, I think your proposal is good. I could not come up with any better attribute or token names, other than perhaps hyphenating the ones you suggested. Maybe impose-role would be easier for humans to parse? Consider also adding hyphens to the values: override-target and keep-target . Cheers, Gershon Gershon L Joseph Senior Information Architect Precision Content Phone: +972 ( 54) 658-3887 TZ : Jerusalem, Israel (GMT+2) Email: [email protected] Twitter: @PCASinc www.precisioncontent.com 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 180 John St. Toronto, ON Canada M5T 1X5 T: (647) 557-5965 [email protected] 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 From: [email protected] <[email protected]> On Behalf Of Robert Anderson Sent: Saturday, June 25, 2022 12:16 AM To: [email protected] Subject: [dita] Early feedback on Issue 670, Impose Role Hi all, As discussed at the TC this week, I'm sending along the draft of the "impose role" topic. It's the proposal for an actual defined way to manage the behavior that is currently described here: http://docs.oasis-open.org/dita/dita/v1.3/errata02/os/complete/part1-base/archSpec/base/cascading-of-roles-in-specialized-maps.html#cascading-of-roles-in-specialized-maps Based on discussion at TC, I've set up a new attribute to control this, called "imposerole". I really do not want to use yes/no values because that has bitten us several times in the past, when we suddenly discover there is a third option. So I've picked a couple of tokens that more or less make sense to me: keeptarget == whatever the target is, it stays that. You don't impose your role. So if you reference a generic <topicref>, you end up with a generic topicref. overridetarget == override whatever the target is. If you are a chapter and you reference a generic <topicref>, you impose your role and end up with a chapter. Do those make sense, or does anyone have a better set of tokens? Thanks, Robert