stevedlawrence commented on code in PR #862:
URL: https://github.com/apache/daffodil/pull/862#discussion_r1008035417
##########
daffodil-japi/src/main/scala/org/apache/daffodil/japi/Daffodil.scala:
##########
@@ -1155,3 +1156,23 @@ class DaffodilUnparseContentHandler private[japi]
(sContentHandler: SDaffodilUnp
override def skippedEntity(name: String): Unit =
contentHandler.skippedEntity(name)
}
+
+/**
+ * Returns the EntityResolver used by Daffodil to resolve import/include
+ * schemaLocations.
+ *
+ * DFDLCatalogResolver uses an org.apache.xml.resolver.Catalog/CatalogManager
to
+ * attempt to resolve namespaces and systemId's. If we are unable to resolve a
+ * file with the Catalog, we attempt to resolve the file using the systemId
path
+ * from the schemaLocation attribute. If this fails we throw a
Review Comment:
Ah, I guess that makes sense, and it just depends on if the root schema was
found in on the classpath or the filesystem. If the root schema was found on
the classpath all imports will look on the classpath (since they are relative
to things found on the classpath), and likewise with the filesystem.
So maybe instead of mentioning the classpath we say something like,
catalogmanager is first, otherwise schemaLocations are resolves relative to the
importing schema URI, which could be a file on the filesystem or in a jar on
the classpath. Probably can be worded better, but something like that to make
it clear we support classpaths or file depending on the original root schema.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
