On 12/28/20 7:21 PM, Don Brutzman wrote: > On 12/28/2020 12:49 PM, Steve Lawrence wrote:
-- clip -- > > I had felt the urge to add a local copy of the schema because > double-checking with XMLSpy throws an error on the schema otherwise: Ah, yes, if want to use the schema as an XML schema, you may need to include this file to suppress warnings/errors. Note that this file doesn't have any actually XML schema information in it. It only contains DFDL annotations, so if something like Ant or XML Spy were to ignore this particular include, the schema should still behave correctly. That might not be an option though. > Perhaps it would be nice if there was a well-defined online URI that an > DFDL engine might similarly provide (with online retrieval) via an XML > catalog, that would allow validation of the schema to proceed properly. > > * <xs:include > schemaLocation="org/apache/daffodil/xsd/DFDLGeneralFormat.dfdl.xsd"/> That's not a bad idea. We could perhaps do something like <xs:include schemaLocation="http://daffodil.apache.org/xsd/DFDLGeneralFormat.dfdl.xsd"; /> However, I think some schema validators don't actually download schemaLocation URL's, and there are some security concerns related to this (see DFFODIL-602). But we could make it so Daffodil only looks in jars and will not go off box for this special URI, and it makes it an obvious place for people to find this file if they do need to manually download it. I'll open a ticket for this. >> b) This is the most recent version of the CSV schema. The issue you're >> seeing is that the encodingErrorPolicy is set to "error" in >> csv.dfdl.xsd, but Daffodil does not support this value--we only support >> encodingErrorPolicy="replace". > > Thanks for explanation. > > Looks like this property is fully explained at > > * DFDL Spec, 11.2.1 Property dfdl:encodingErrorPolicy > https://daffodil.apache.org/docs/dfdl/#_Toc54264422 > > Interoperability (via specification compliance) is of course helpful. > > Warnings are also helpful, and should lead to fixes. Eliminating > warnings is best case, so that the presence of "expected" warnings > doesn't hide the presence of unexpected warnings. > > Curious what the long-term resolution of this might be, presumably > - Apache Daffodil support for encodingErrorPolicy="error" > - Similar IBM DFDL support for encodingErrorPolicy="replace" > Yep, we have a bug to support "error" (DAFFODIL-935). Mike Beckerle just bumped up the priority of this, but it's has a handful of subtle edge cases to deal with, so I can't say when it will be fixed. Unfortunately, I don't have any insight into IBM's plans to support "replace".
