Attribute values from a DITA subjectscheme to the insert attributes drop-down list

[bjarne.melin]

Hello Adepters,

I'm going to use the new TIA application with Arbortext Editor 6.0 M040 for a project and want to provide enumerations of desired attribute values in the Insert Attribute dialog box.

For example, I'm going to use many values for the outputclass attribute to get the desired output. To make the authoring as intuative as possible we want to get the insert attribute dialog box loaded with our predifined attribute values for different elements.
I try to avoid touching the schema, even if I know it's an option in such cases.

Obviously, this could be done by defining keys in a Subjectsheme map.
Actually I saw a Youtube video demonstration about how this could be done with the Oxygen XML Editor, and I suppose it also must be possible to do with Arbortext Editor - but HOW? - I have surfed on the PTC Knowledge database, but haven't found an answer.

The Youtube video was at: (from about 15 minutes in the video to the end)
http://www.youtube.com/watch?v=MPt6wZ2wYig&feature=relmfu

So my question is:
How can I populate the Insert Attributes drop-down list with defined Attribute values from a DITA subjectscheme.

For example, enumeration of values to use for the outputclass attribute for the <ph> element.
Any suggestion about how to do this would be greatly appreciated!

Bjarne Melin
Freelance Document Architect

[bibach]

Per the "DITA Standard Support" topic in the help center for Editor 6.0
M050, the subject scheme feature of DITA 1.2 (referred to as "Controlled
values and taxonomies") is not currently supported.

However, Editor's profiling feature, which is available for any document
type, provides much of the same functionality. I don't know if it will
work with the outputclass attribute (haven't tried, myself), but you may
want to use one of the standard DITA conditional processing attributes
(audience, platform, product or otherprops), anyway. The outputclass
attribute is, by design, intended as a sort of "escape hatch" when no other
mechanism is suitable, ideally on a temporary basis pending a solution via
specialization.

The main limitation of profiling compared to a subject scheme, as far as I
can see, is that profiling is configured globally for your document type,
whereas you can use different subject schemes for each DITA map. If you
have need for this kind of flexibility, you might consider creating one or
more "skeleton" specializations that are really just plain DITA with
different names, such that you can configure them differently. Your
document type's DCF file points to a PCF file that configures the profiling
feature, including labels and allowed values for each attribute.

-Brandon 🙂

[bjarne.melin]

Thank you Brandon for the answer!

Good to know that Subject Scheme support isn't yet implemented in Arborbortext editor,
so I have to choose another way to obtain the desired result. Using an 'authoring schema'
that validates against the standard schema seemed to be the easiest solution for now.

Afaik. using profiling and other settings in the DCF file can't be done so it only affects
an attribute for a certain element. Instead it affects the behavior of the attribute on ALL
elements with that attribute, and that is not what I want...

///Bjarne

In Reply to Brandon Ibach:

Per the "DITA Standard Support" topic in the help center for Editor 6.0
M050, the subject scheme feature of DITA 1.2 (referred to as "Controlled
values and taxonomies") is not currently supported.

However, Editor's profiling feature, which is available for any document
type, provides much of the same functionality. I don't know if it will
work with the outputclass attribute (haven't tried, myself), but you may
want to use one of the standard DITA conditional processing attributes
(audience, platform, product or otherprops), anyway. The outputclass
attribute is, by design, intended as a sort of "escape hatch" when no other
mechanism is suitable, ideally on a temporary basis pending a solution via
specialization.

The main limitation of profiling compared to a subject scheme, as far as I
can see, is that profiling is configured globally for your document type,
whereas you can use different subject schemes for each DITA map. If you
have need for this kind of flexibility, you might consider creating one or
more "skeleton" specializations that are really just plain DITA with
different names, such that you can configure them differently. Your
document type's DCF file points to a PCF file that configures the profiling
feature, including labels and allowed values for each attribute.

-Brandon 🙂