I am forwarding this e-mail from the dita-users list, since it raises questions that we need to consider: How should processors handle multiple subjectScheme maps that are referenced by a root map or its children maps? How should processors handle subjectScheme maps that are referenced from within a key scope? The spec is clear about how subjectScheme maps that are referenced using a <schemeref> element should be used to extend enumerations of controlled values; see
http://docs.oasis-open.org/dita/dita/v1.3/os/part1-base/archSpec/base/extending-a-subject-scheme.html#concept_bxc_hmj_zq (normative topic),
http://docs.oasis-open.org/dita/dita/v1.3/os/part1-base/archSpec/base/example-subjectScheme-extension.html (non-normative example), and
http://docs.oasis-open.org/dita/dita/v1.3/os/part1-base/archSpec/base/example-subjectScheme-extension-upwards.dita.html (non-normative example). However, the spec does not explicitly address address the question of whether subjectScheme maps that are referenced by regular <topicref> elements or specializations thereof extend enumerations in a similar fashion. Is this scenario covered by default expectations about how processors simply handle keys? Best, Kris Kristen James Eberlein Chair, OASIS DITA Technical Committee Principal consultant, Eberlein Consulting
www.eberleinconsulting.com +1 919 682-2290; kriseberlein (skype) On 7/5/2016 6:05 PM,
lwwhite5@hotmail.com [dita-users] wrote: 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 Reply via web post • Reply to sender • Reply to group • Start a New Topic • 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 . __,_._,___