While I'm thrilled that a hack may not be needed, I do not at all agree with Martin's characterization of Perl as "mysterious". Yes, it's string processing (not node processing), but (IMHO) if you're going to do string processing Perl is one of the, if not the, least mysterious ways to do it. It is *very* widely known, built-in on most all reasonable systems, and is readily available even on Windows.[1] It is stable enough that it's extraordinarily unlikely that such a command would fail to work with a future version of Perl. And the point of putting the search-and-replace in my previous post was to point out how simple it is. And now that I think about it, even if we can re-define model.common, and thus duck this bullet ourselves, shouldn't ODD processing do the right thing for someone else who stumbles into this problem? Notes ----- [1] Although Martin's right, we can't just call it willy-nilly on Windows. But I don't have any desire to try to support building on Windows, myself.
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.
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.