I agree with Syd: the last thing we want to do is hobble Pure ODD for the sake of supporting DTDs. How about a pre-processor step that detects this Pure ODD context and wraps it in a sequence? Cheers, Martin On 15-08-24 07:38 AM, Syd Bauman wrote:
I'm thinking that since ((%model.global;))* is the same (for validation) as (%model.globa;)* that the brain-dead change for (d) is to always emit a set of parens, no? Thus we'd end up with ((%model.divBottomPart;),((%model.global;))*)* which, while ugly, should work. And I'd much prefer to generate ugly output DTDs then have ugly input Pure ODD content models.
(I am discounting the idea of expanding parameter entity references as undesirable ... although we do have the source code for Carthage.)
But all that said [insert whining about needing to support DTDs here].
And I don't see any silver bullets, Lou,
You may be wondering how Pure ODD is progressing...
Well, all over the place, there are bits of content model like this (expressed in pure ODD)
<sequence minOccurs="0" maxOccurs="unbounded"> <classRef key="model.divBottomPart" /> <classRef key="model.global" minOccurs="0" maxOccurs="unbounded"/> </sequence>
i.e. there may be nothing here at all, or there may be at least one member of the model.divBottomPart class possibly followed by some model.globals.
This makes perfect sense when transformed to RelaxNG or even in XSD, but the DTD fragment we get for it is:
(%model.divBottomPart;,(%model.global;)*)*
which is not syntactically correct in DTD language. It needs to be
((%model.divBottomPart;),(%model.global;)*)*
Alas, using the current oddtodtd, those extra parens only appear if the bare class reference is inside either a sequence or an alternation. But we have a schematron rule that says (reasonably enough) that a <sequence> must have two or more children. (We don't see this problem in the impure ODD, of course, because RelaxNG doesn't mind <group>s containing just a single pattern)
This is not an isolated problem, either.... it's a favourite trick in our content models.
Having spent most of today on this, I am reluctantly coming to one of the following conclusions: a) we should just abandon DTDs b) I could write a dirty hack to detect these things and post process the DTDs c) we should quietly drop the schematron rule d) someone (not me) should rewrite odd to dtd either to deal with these things properly or (more radically) to expand all parameter entities e) there is another silver bullet somewhere but i am too stupid to see it
Any opinions? Recommendations?