dependencies in cc_config.xml

[OliverG]

Hi there,
I ran into an odd problem with cc_config.xml:
I put for example

Code: Select all

<valueProposals path="tei:div/@type"> ... </valueProposals>
<valueProposals path="tei:p/@type"> ... </valueProposals>

in this order, while my document (TEI) had <p> as child of <div>:

Code: Select all

<div><p>...</p></div>.

Then the proposed values for "tei:div/@type" were also shown on <p> and were in fact overriding the second value proposals.
BUT: When I reversed the order of the value proposals in the config file to

Code: Select all

<valueProposals path="tei:p/@type"> ... </valueProposals>
<valueProposals path="tei:div/@type"> ... </valueProposals>

it worked.
I verified this with <lg> / <l> respectively.
So my question is, whether there are intrinsic rules for setting up the cc_config.xml, which I don't know and only stumbled upon by trial and error.
Many thanks for any help in understanding what I'm actually doing here.
Kind regards
Oliver

[chrispitude]

Hi Oliver,

I was able to reproduce this with the @outputclass attribute in the following testcase:

cc_config_experiment.zip

[OliverG]

Hi Chris,
thanks for confirming this.
It looks like a bug, doesn't it? I mean the respective paths are different and explicitly given. So why is - in your example - "div/@outputclass[values-for-div]" overriding "p/@outputclass[values-for-p]"? I'm curious for the explanation.

[chrispitude]

Hi Oliver,

It does seem like a bug to me too.

[alex_jitianu]

Hi,
Olivier, thank you for reporting this issue. Chris, thank you for confirming it and for the samples. I also confirm that this is an indeed an issue. I've recorded an issue to investigate and understand the issue and hopefully we will release the fix for the next release.

Best regards,
Alex

[OliverG]

Thank you, Alex, for your response and action.