Open lb42 opened 6 years ago
Re the second point: I've never understood why the order of children in an elementSpec or attDef is constrained. Is there a reason?
No ampersand connector in XML.
Eh?
Constraining the order of components in an element we are defining doesn't seem such a problem to me. The order is arbitrary, obviously, but requiring that it always be the same makes validation an awful lot simpler. Especially in the absence of features like the ampersand connector, or interleave.
see also #210 for other ways of getting an invalid schema out of an apparently correct ODD
This issue is now 5yrs old
Today I also stumbled over the invalid empty attList
generated when I was compiling my ODD with odds/odd2odd.xsl
. It's inline element statements that simply create the attList
elements, no matter what the $ORIGINAL
or elementSpec
in the customisation state, e.g.:
For a simple local fix I just wrapped it in:
<xsl:if test="tei:attList or $ORIGINAL/tei:attList">
…
</xs:if>
And voilà :-)
Thank you, @bwbohl. I think that fix looks right, but (as you point out on the PR) this should also happen for an <attList>
in a <classSpec>
. (And the tests are failing, although I suspect that has nothing to do with your code.) I am pessimistic about getting this into the upcoming release, but have high hopes we can get it into the one after.
It has been waiting 5 years...
I took the liberty of assigning this ticket to @trishaoconnor.
She can merge PR https://github.com/TEIC/Stylesheets/pull/630 without problem and that fixes the empty <attList>
issue. What it’s missing now is to determine which other of the issues raised by @lb42 are still present.
@sydb and I investigated the issue described in point two, that the constraintSpec element was appearing before the datatype element. We believe we found the section in the odd2odd.xsl that was causing the problem and resolved it by reversing the order in the template, see PR #675.
We didn't find any instances to support the third point "a <p>
inside a <specGrp>
is invalid".
As noted in #212 the current oddtoodd process generates invalid ODDs. Specifically:
Compiling the ODD for teisimplePrint,odd exhibits all these problems; there may of course be others.