OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [dita] Key scopes for subjectdef versus controlled attribute values


I agree with your assessment that they should be resolved/restricted to “user” and “admin” in your example. Whether the wording in the spec reflects that understanding, I’m not sure…

Thanks and best regards,

Scott Hudson
Senior Consultant
Comtech Services Inc.

From: Robert D Anderson
Date: Friday, April 3, 2015 at 9:13 AM
To: "dita@lists.oasis-open.org"
Subject: [dita] Key scopes for subjectdef versus controlled attribute values

While working through action items about keys in the spec, I realized I'm still unclear on one thing about key scopes and subject schemes.

Assume that I have my taxonomy and controlled values in a subject scheme map. The map is pulled into my root map with the key scope set to "tax". The scheme is used to set up all my taxonomy subjects, and to set controlled values for @audience, @platform, and @product.

I can use the <subjectref> element to reference subjects. In this case I think it's clear that I should include the scope, because these keys resolve just as any other keys:
<subjectref keyref="tax.myproduct"/>

I'm not clear what we determined for attribute values. Assume the subject scheme defines the keys "user" and "admin", then restricts @audience to just those values. Looking at the subject scheme in isolation, it appears I'm restricting @audience to the literal values "user" and "admin", which are also key names.

The question is - in the broader context of the root map, where I've put my subject scheme into the key scope "tax", what values are valid for @audience? In topics referenced from my map, is @audience restricted to "user" and "admin", or is it restricted to "tax.user" and "tax.admin"? I think we decided it's the former because doing otherwise will be difficult (if not impossible) to manage. But, I feel we've gone around on these issues enough that I need to double check before moving forward.

Thanks -

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit (http://www.dita-ot.org/)

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]