ODD problem with setting up alternative groupings of @type and @subtype on rs element

[ebeshero]

In the project ODD, I'm working on customizing the values of @type and @subtype for the <rs> element. I'm working on defining alternative groupings, so that particular values of @type may only be paired with particular values of @subtype. I followed my own example that I prepared to do exactly this a year ago for this TEI ticket: TEIC/TEI#2140 but I'm having strange problems with this project ODD: The output Relax NG will only validate one closed list of @type values that are paired with an open @subtype and the other pairings aren't recognized at all.

Here's the ODD (on a branch until I can get it to properly validate our TEI): https://github.com/newtfire/locke-anthology/blob/oddWork/odd/lockeAnthology.odd

@sydb @djbpitt Would either of you take a look at this and see if you can spot what I'm doing wrong with this ODD?

[ebeshero]

@sydb @djbpitt Well! I just stumbled into the repair for this ODD, but I don't like it.
To get it working I had to make all the valLists for @subtype in each <attList org="group"> be @type="semi". It's not really what we want here: these are supposed to be closed valLists for both @type and @subtype with the exception of just one, where I'm leaving the valList open for @subtype or could even just remove it. But the ODD outputs the appropriate pairings and the Relax NG properly validates this project's TEI at last, so I suppose I'm satisfied for now.

I'm not satisfied with this for the TEI, though: I think it's bad ODD behavior and don't understand why I have to make semi valLists to get alternate groupings to work!

[ebeshero]

Here's how I patched the ODD to get it working: c36c95a

[sydb]

At first blush sure looks like a Stylesheets error. I did tests with and both "semi" and "closed", same result. Will make a small test ODD now.

Yup. Per my little test ODD (which always uses <datatype><dataRef key="teidata.enumerated"/></datatype>, as I think it should be required) any case with both child <attDef>s being of "closed" value lists fails. I have not tried > 2 child <attDef>s nor swapping the order. Maybe later.