I tend to agree with Martin here, but on the other hand it may not be necessary to do this unclean thing. I now think the problem is less wide spread, and may simply entail a tweak to the way model.common is defined. More later (I am still on the road, but having reached Santiago de Compostela, will soon be returning to Oxford and normal internet connectivity. If anyone tells you that the rain in spain falls mainly on the plain, believe me, they are mistaken. On 24/08/15 19:31, Martin Holmes wrote:
I instinctively balk at any more mysterious PERL finding its way into our ODD processing. This can be done with XSLT -- not very elegant, toon the track of a solution... be sure, but it would keep the number of technologies in our processing chain to a minimum. I keep hearing that people want to be able to do this stuff on Windows, so an ant project with no shell callouts would be favourite.
Cheers, Martin
On 15-08-24 08:14 AM, Syd Bauman wrote:
If it comes to a separate processing step, I'd prefer a post-processor that detects this and wraps the offending reference in parens. perl -pe 's/(%[A-Za-z][A-Za-z0-9.-]+;),/($1),/g;' < in.dtd > out.dtd
Or, as I said, *all* of 'em. perl -pe 's,%[A-Za-z][A-Za-z0-9.-]+;,($&),g;' < in.dtd > out.dtd
Of course, these make the mistake of hitting those that are in comments, too. But since the DTD file is generated output that we generate, this doesn't worry me too much.
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?