UPA errors are detected by xerces if the schema-full-checking feature is turned on, AND if you inform xerces that it is reading an XML Schema (i.e., xsd).
UPA errors are detected by xerces if the schema-full-checking feature is turned on, AND if you inform xerces that it is reading an XML Schema (i.e., xsd).
Detecting these requires that we do THREE passes 1) load the DFDL schema as an XML document. This validates it against the XML Schema for DFDL schemas. 2) load the DFDL schema as an XSD - xerces then does lots of more intensive checking of the schema 3) load the schema for our own consumption by Daffodil code. This uses the constructing parser so as to preserve CDATA regions (xerces just does the wrong thing with those,...fatally so). Then our own semantic checking is performed as part of compiling the DFDL schema.
Checks like UPA are in step (2) above. They are coded algorithmically right into Xerces. This is accomplished by using the below SchemaFactory and SchemaFactory.newSchema calls. The newSchema call is what forces schema validation to take place.
This loads the DFDL schema as an XML Schema.
This loads the DFDL schema as an XML Schema. This will check many more things about the DFDL schema other than just whether it validates against the XML Schema for DFDL schemas.
Unfortunately, we don't have control over how Xerces loads up these schemas (other than the resolver anyway), so we can't really redirect the way it issues error messages so that it properly lays blame at say, the schema fragments inside an embedded schema of a TDML file.
So if we want good file/line/column info from this, we have to give it a plain old file or resource, and not try to play games to get it to pick up the file/line/col information from attributes of the elements.
Manages the care and feeding of the Xerces schema-aware XML parser that we use to do XML-Schema validation of the files we are reading.