How does Roma decide which schemaSpec to process?

[cmsmcq]

I am working on an ODD document for a set of three interrelated customizations of TEI. They are defined in a single ODD document because they share a good deal of material; having them in three separate ODD documents would be a maintenance disaster.

The Roma interface appears to exhibit two flaws when presented with such a document.

First, I haven't been able to locate any mechanism for specifying which schemaSpec element to process. (Perhaps I just haven't looked in the right place.)

Second, the lists of modules and extension elements it provides appear to be based on the assumption that every elementSpec in the document with mode="add" is to be added to the schema being generated, whether it's in a specGrp reachable by specGrpRef pointers from the root schemaSpec or not. (I have a schema fragment showing an imaginable initial declaration for a couple of elements which is not actually referred to from anywhere else, and then the real declarations later, following a discussion of where the initial declarations fall short of requirements. Roma shows multiple extensions using the same name.

The ODD in question is on the open web at http://uyghur.ittc.ku.edu/2018/05/atmo-schemas-PTS.xml

[lb42]

The Roma interface, if you mean the web interface, is fairly simple minded in what it expects to find and to generatre. It's more significant if you mean that the TEI stylesheets in general don't handle this situation correctly; I'm looking into that but am initially thrown by the fact that your ODD isn't valid against the current release of tei_odds.rng (uses a defunct attribute @status; <datatype> has invalid content) .

[cmsmcq]

The web interface is indeed what I mean. It is the also the only thing I see labeled Roma.

The package TEIC/Stylesheets handles the situation fine; passing the --schema parameter has the desired effect. I was trying to document the generation of schemas from the ODD document for the benefit of some future maintainer of the schemas, after I am hit by a bus or otherwise no longer available, and expected that Roma would be a good solution for them. In its current incarnation, it's not.

The document is valid against the ODD schema I have, and I have no interest in trying to hit a moving target. If Roma relies on validity against some later schema against which my input is invalid, some questions seem natural to ask: why is TEI making backward incompatible changes to the schema? And why does Roma not report validation errors to the user? And why is Roma not made to be backward compatible?

[lb42]

There used to be a command line version of roma, is why I was checking.
I dont think I'd recommend Roma to future maintainers of anything: its future is far from secure. Whereas the command line utilities are well supported and work.
Validity against the current TEI schema is not required for the stylesheets to do the right thing, evidently. I just think it;s a good thing in general, so I start from there. FYI, the datatype content model change e is something that has been around since "pure ODD" was introduced quite a while ago now, so I am surprised you haven't hit it before. The other problems with your ODD are just to do with the Council having decided to call the damn thing "schematron" and not "isoschematron" any longer. Why they didn;t allow the old name to continue I will leave someone else to explain.
All questions in the form "Why is Roma ...." have the same answer, I fear, and I gave it on your other ticket.