Subject scheme map: Profiling attribute values not picked up

[Frank Ralf]

Hi,

I'm using a subject scheme map to provide controlled values for a profiling attribute. However, I encounter a very strange behavior as some values are not picked up from the subject scheme map and are marked as invalid if used. In addition, I've also defined the values in oXygen's Profiling Settings on project level. Of the following subject definitions, "pkc" and "puf" don't show up as valid values.

Code: Select all

<subjectdef keys="pkc" />

<subjectdef keys="pkc_OFF" />

<subjectdef keys="puf" />

<subjectdef keys="puf_OFF" />

This strange behavior is reproducible on another machine when using the same oXygen project file. When using the same subject scheme in another oXygen project everything works as expected. Therefore I suspect the error being caused by the project file itself but I cannot find anything suspicious when peeking under the hood. This starts to drive me crazy

Any pointers welcome.

Best regards,
Frank


(oXygen 16.1, Windows 7)

[Radu]

Hi Frank,

If you email us (support@oxygenxml.com) a small project exhibiting this problem we could give you more hints.
If your main DITA Map (opened in the DITA Maps manager view or selected in the Root Map combo box) references directly or indirectly the subject scheme map, controlled values will only be obtained from the Subject Scheme map so the values that you set in the Oxygen preferences for those same attributes should be ignored completely.

Regards,
Radu

[Frank Ralf]

Hi Radu,

Thanks for your kind help. I will try to create a project that exhibits this behavior and send it to your support address.

Best regards,
Frank

[Frank Ralf]

I've found the culprit. We have defined a key that is identical with a subject definition. And as both are specialized from <topicref> they get in each other's way.

So if you have the following subject scheme:

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE subjectScheme

  PUBLIC "-//OASIS//DTD DITA Subject Scheme Map//EN" "subjectScheme.dtd">

<subjectScheme xmlns:ditaarch="http://dita.oasis-open.org/architecture/2005/">



  <subjectdef keys="audience_options">

    <subjectdef keys="homer" />

    <subjectdef keys="lisa" />

    <subjectdef keys="marge" />

  </subjectdef>



  <enumerationdef>

    <attributedef name="audience" />

    <subjectdef keyref="audience_options" />

  </enumerationdef>



</subjectScheme>

And the following key definition:

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE map PUBLIC "-//OASIS//DTD DITA Map//EN" "map.dtd">

<map>

 <title>Mystery key definitions</title>

  

  <keydef keys="lisa">

    <topicmeta>

      <keywords>

        <keyword>Lisa Simpson</keyword>

      </keywords>

    </topicmeta>

  </keydef>

  

</map>

Then "lisa" will not be shown as an allowed value.

Best regards,
Frank

[Frank Ralf]

An additional observation. The order of the references to the key definitions and the subject scheme in the top map seem to matter:

Works: Subject scheme > Key definitions
Does not work: Key definitions > Subject scheme

Best regards,
Frank

[Radu]

Hi Frank,

Right, without key scopes according to the specs the first key with a particular name encountered by the application when traversing the DITA Maps hierarchy will be used.

Regards,
Radu

[Frank Ralf]

Hi Radu,

I've tried key scopes with this use case and they work like a charm. Unfortunately, we are still using DITA 1.2 with this customer.

Best regards,
Frank

[energo]

Subject scheme extending - not working.
As soon as in DITA specs we see only SubjectScheme relations, there is not distinct way to accomplish this together with ordinary dita maps.

The version XML Editor 21.1, build 2019061404 OSX doesn't seems to support example with baseOS.ditamap and it's extension.

Would You mind having some working example with Your DITA examples with UPWARDS and DOWNWARDS subject scheme extending scenarios?
Nice would be to mix it with HasNarrower , HasPart example?

OR maybe this is the gate for payable support ?

[Radu]

Hi,

Right now Oxygen tries to use the Subject Scheme information to impose attribute values when editing and validating. We do not use the "HasNarrower" and "HasPart" elements for anything. Also the default publishing does not use most of the Subject Scheme content (it uses only the parts which describe profiling attribute value hierarchies in order to filter based on them).

Coming back to your questions, I'm sorry but I do not understand what does not work for you. How about if you prepare an example and tell us more about how you would expect the application to behave in this regard?

About this remark:

OR maybe this is the gate for payable support ?

We have the concept of maintenance pack which allows you to benefit of tech support priority and a free upgrade to the next Oxygen major version. Paid or unpaid support, we'll try to help as much as possible.

Regards,
Radu

[energo]

We

Coming back to your questions, I'm sorry but I do not understand what does not work for you. How about if you prepare an example and tell us more about how you would expect the application to behave in this regard?

We need working example UPWARD/DOWN extending profile attributes with ditamaps implementing subject schemes (probably 2 ditamaps, 2 subject schemes, 2 subject schemes with enumerationdef (ive read that it should be separated))

[Radu]

Hi,

The only examples we can provide are the ones in our documentation :

https://www.oxygenxml.com/doc/versions/ ... e-map.html

and also the Subject Scheme map we use for the Oxygen's user's manual:
https://github.com/oxygenxml/userguide/ ... ls.ditamap

If this is not enough maybe you can consider registering and asking about this on the DITA Users List.

Regards,
Radu