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
LinkedIn | Twitter | YouTube | Facebook
From:
dita@lists.oasis-open.org <dita@lists.oasis-open.org> on behalf of Gershon Joseph <gershon@precisioncontent.com>
Date: Sunday, June 26, 2022 at 9:32 AM
To: Robert Anderson <robert.dan.anderson@oracle.com>, dita@lists.oasis-open.org <dita@lists.oasis-open.org>
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: gershon@precisioncontent.com|
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 |
|
|
|
|
||
|
|
||
From: dita@lists.oasis-open.org <dita@lists.oasis-open.org>
On Behalf Of Robert Anderson
Sent: Saturday, June 25, 2022 12:16 AM
To: dita@lists.oasis-open.org
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:
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