Re: [tei-council] let me share my pain

Thanks for the offer Hugh : I can't do so immediately because obviously you wont see anything wrong unless you've installed the "purified" specs, or a local p5.xml derived from them. Which you can't yet because I haven't checked them into the "P5-Pure" branch (because they break the build). But thinking about how to demonstrate the problem more simply led me a bit further into the maze, so I may be back anon. yours currently trundling across Galicia and therefore only intermittently online Lou On 17/08/15 16:25, Hugh Cayless wrote:

If you can give me an example ODD that produces a broken DTD, I could have a go at option d. Seems like something it should cope with...

On Fri, Aug 14, 2015 at 1:02 PM, Lou Burnard wrote:

...

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?

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived