Topics

note type vs othertype #specialization

Stuart Norton <stu.norton@...>
 

I'm looking for some suggestions on how to represent custom note types in DITA... We have a couple of custom note types, such as a "best practice" that is presented with a special icon. In DITA, it looks like we could either:
1. Permit new attribute values: e.g. note with type = "best-practice"
2. Use type = "other" with othertype = "best-practice" (and configure the editor to suggest that option so authors don't have to remember/type it)

 

It seems like #2 is what the DITA designers intended, but #1 seems like it would be a bit more straightforward for the authors to use.

(I am not clear on whether #1 would actually be considered a specialization, since it seems to break the usual rules for specialization by expanding the available values?)

Any recommendations?

Thanks!

ekimber@contrext.com
 

Your option (2) is the correct way to do it (that is, the set of pre-defined note types is not intended to be directly extended).

Normally you'd take the next step and create a specialization of <note>, i.e, <best-practice>, that sets the type and othertype attributes as defaults so authors never have to worry about setting othertype.

That is, if you are prepared to redeclare the values of @type you might as well do the specialization.

Alternatively, you should be able to configure your editor to make it convenient for authors to create <note> with specific type and othertype values.

But the semantic "best-practice" seems more than strong enough to justify doing the specialization.

Cheers,

E.

--
Eliot Kimber
http://contrext.com


On 11/22/19, 1:20 PM, "Stuart Norton" <dita-users@groups.io on behalf of stu.norton@...> wrote:

I'm looking for some suggestions on how to represent custom note types in DITA... We have a couple of custom note types, such as a "best practice" that is presented with a special icon. In DITA, it looks like we could either:
1. Permit new attribute values: e.g. note with type = "best-practice"
2. Use type = "other" with othertype = "best-practice" (and configure the editor to suggest that option so authors don't have to remember/type it)

It seems like #2 is what the DITA designers intended, but #1 seems like it would be a bit more straightforward for the authors to use.

(I am not clear on whether #1 would actually be considered a specialization, since it seems to break the usual rules for specialization by expanding the available values?)

Any recommendations?

Thanks!

Nicholas Mucks
 

Hi!
We use custom note types without specialization. It’s an update to the XSL template for notes and then an updated localization variable. For example, we have a special warning symbol used for electric shocks.

Take care,
- Nick

Sent from mobile

On Nov 22, 2019, at 1:49 PM, "ekimber@..." <ekimber@...> wrote:

Your option (2) is the correct way to do it (that is, the set of pre-defined note types is not intended to be directly extended).

Normally you'd take the next step and create a specialization of <note>, i.e, <best-practice>, that sets the type and othertype attributes as defaults so authors never have to worry about setting othertype.

That is, if you are prepared to redeclare the values of @type you might as well do the specialization.

Alternatively, you should be able to configure your editor to make it convenient for authors to create <note> with specific type and othertype values.

But the semantic "best-practice" seems more than strong enough to justify doing the specialization.

Cheers,

E.

--
Eliot Kimber
http://contrext.com


On 11/22/19, 1:20 PM, "Stuart Norton" <dita-users@groups.io on behalf of stu.norton@...> wrote:

I'm looking for some suggestions on how to represent custom note types in DITA... We have a couple of custom note types, such as a "best practice" that is presented with a special icon. In DITA, it looks like we could either:
1. Permit new attribute values: e.g. note with type = "best-practice"
2. Use type = "other" with othertype = "best-practice" (and configure the editor to suggest that option so authors don't have to remember/type it)

It seems like #2 is what the DITA designers intended, but #1 seems like it would be a bit more straightforward for the authors to use.

(I am not clear on whether #1 would actually be considered a specialization, since it seems to break the usual rules for specialization by expanding the available values?)

Any recommendations?

Thanks!