I missed this email so I'm a little late, but +1 to deprecating XML catalogs.
On 6/4/21 6:48 PM, Beckerle, Mike wrote: > I spent quite a bit of time this week trying to get 2 DFDL schemas using XML > Catalogs to work. > > I succeeded, but I find XML Catalogs very fragile, with important aspects > that > don't work (I was unable to get relative-catalogs to work at all) and I am > wondering if we really need to support XML Catalogs not. Our classpath based > resolution of schema locations works quite well and can be used to make quite > modular DFDL schemas. > > Currently, XML schemas built into Daffodil (e.g., tdml.xsd, the schema for > DFDL > schemas, etc.) are resolved from a built-in XML catalog, but really the fact > that this is using a catalog is not particularly important. You can think of > it > as they're just built into our resolver. > > XML Schemas referenced using the schemaLocation attribute on an > xs:import/xs:include or the xsi:schemaLocation on XML instance documents are > resolved by either: > > 1) relative to the file containing the reference, i.e., the file containing > the > include/import statement > > 2) relative to the root of any directory or jar on the classpath, searching > them > in classpath order. First one found wins. > > This enables one to create multi-part DFDL schemas, such as for an envelope > format, and a payload format carried inside the envelope format. Each can be > testable separately, and a combining schema can be created that puts the > payload > on the classpath first, followed by the envelope format, and combines the two. > > Given that this works, and works well, I am wondering if we should just > deprecate the XML catalog feature. > > Thoughts? > > Mike Beckerle | Principal Engineer > > mbecke...@owlcyberdefense.com <mailto:bhum...@owlcyberdefense.com> > > P +1-781-330-0412 >
