Although our testing infrastructure appears to heavily rely on built-in-formats.xsd, I still think it needs be to deprecated and eventually removed. Having real world schemas that reference "tns:daffodilTest1" is clearly wrong. And we probably don't want TDML files using that since those are obvious starting points as a reference when building a new schema. So I feel this must be deprecated, and if we are going to deprecated it, I'd rather go through the headache now and be done with it.
To deprecate this without too much pain, it seems reasonable to me to create our own version of IBM's GeneralPurposeFormat (which actually has odd choices for defaults IMO) and modify our TDMLRunner to use that. I think modifying all our tests to reference that should be pretty easily scriptable. I'm fine putting built-in-formats back in and adding some backwards compatibility that isn't quite so aggressive as what let to this change. If done right, I'm a little more optimistic about this not causing subtle bugs since it's would essentially just be a rename. I'll spend a little time this morning investigating this change. - Steve On 02/14/2018 04:46 PM, Mike Beckerle wrote: > This change is causing no end of headaches. I have wasted a day already > fixing things that are now broken on account of this. > > > Turns out built-in-formats.xsd is *not* only used by our internal tests. > > > It is part of the TDML runner's tdml:defineSchema infrastructure - included > into every such embedded schema implicitly. > > TDML runner is callable/usable from our CLI, which means it is part of the > published non-test daffodil jars. > > > built-in-formats.xsd and daffodilTest1 are also is "out there" in that they > appear on slides that are full of small examples that have been published on > the web for a while now. > > > I think this horse has left the barn, and we're committed to supporting > built-in-formats.xsd as is, in the original location as part of daffodil-lib. > > > If we want to deprecate it in the future in favor of some better named thing > I'm fine with that. But changing this is going to require a deprecate, and > slow-cut over, otherwise it requires a big comprehensive sweep hundreds of > lines of code change, subtle bugs come up. And the changes have to be done in > lots of things that aren't even part of the apache daffodil code base. > > > Also unless DAFFODIL-900 is fixed (missing diagnostic on dfdl:ref not found), > changing any of this stuff is very dangerous. > > >
