Re: [dita-users] Interaction between multiple subjectSchemes in a root m

Hi all,

I've been doing some testing and was wondering what the recommendation is when there are multiple subjectSchemes in a map...what values are made available for the defined attributes. My finding, in one particular XML editor, is that the editor looks first for a subjectScheme referenced by the root map. If one exists, the values enumerated there are made available to the editor's value picklist for that attribute. If more than one exists, and each enumerates different values for, say @audience, then only the @audience values enumerated in the first one are made available to the editor:

MapA
|_MapB
|_MapC
|_subjectSchemeW <-- these values used for @audience throughout root map
|_subjectSchemeX <-- these values ignored for @audience throughout root map

If the second subjectScheme also enumerates values for a different attribute, then those are made available to the editor as well.

MapA
|_MapB
|_MapC
|_subjectSchemeW <-- these values used for @audience throughout root map
|_subjectSchemeX <-- these values used for @product throughout root map

If, in addition, there are subjectSchemes referenced by any child maps of the root map those are all ignored:

MapA
|_MapB
|_subjectSchemeW <-- these values ignored for @audience throughout root map
|_MapC
|_subjectSchemeX <-- these values ignored for @audience throughout root map
|_subjectSchemeY <-- these values used for @audience throughout root map

If there is no subjectScheme referenced by the root map, but there are subjectSchemes referenced by one or more of the child maps, the first subjectScheme encountered is used and the others are ignored:

MapA
|_MapB
|_subjectSchemeW <-- these values used for @audience throughout root map
|_MapC
|_subjectSchemeX <-- these values ignored for @audience throughout root map

It seems in all these respects that subjectdef in a subjectScheme behaves more or less like DITA 1.2 keys...first in wins. Is this the expected behavior?

Going further, it seems that if a subjectScheme is referenced within a child map that in turn is referenced by a
root map, and the child mapref has @keyscope defined, that subjectScheme is ignored altogether by this particular editor, even if it otherwise should be used for value enumeration:

MapA
|_MapB keyscope="B"
|_subjectSchemeW <-- these values ignored for @audience throughout root map
|_MapC
|_subjectSchemeX <-- these values used for @audience throughout root map

This is not at all what I'd expect. I'd expect keyscope to have no effect whatsoever on subjectScheme value enumeration, since nothing is defined on this point in the spec that I can find. It would be *nice* if, say, an editor could recognize the keyspace of an open topic and only present attribute values in the picklist that are enumerated in the effective subjectScheme that is referenced in the same keyspace as the open topic, but again, the spec does not outline this requirement or recommendation.

But again, is the "collision" between @keyscope and subjectScheme expected? I've asked this question of the editor's support as well, but thought I would throw it out here to see what the non-editor-specific feedback might be.

Thanks for any clarification,
Leigh

__._,_.___

Posted by: lwwhite5@hotmail.com

•

•

•

•

Messages in this topic (1)

Have you tried the highest rated email app?

With 4.5 stars in iTunes, the Yahoo Mail app is the highest rated email app on the market. What are you waiting for? Now you can access all your inboxes (Gmail, Outlook, AOL and more) in one place. Never delete an email again with 1000GB of free cloud storage.

Visit Your Group

New Members 4

• Privacy • Unsubscribe • Terms of Use

dita message