Re: Schema fails with newer Xerces
Stanimir Stamenkov <[email protected]> Sun, 2 Mar 2025 15:07:31 +0200
| Newsgroups | gmane.text.xml.xerces-j.user |
|---|---|
| Message-ID | <[email protected]> |
[Re-sending to the mailing list.]
Sun, 02 Mar 2025 11:53:59 +0100, /cz/:
> the Xerces version bundled with the JVM changed from JDK 23 to JDK 24.
> As a byproduct, the OCX Schema
> (https://github.com/OCXStandard/OCX_Schema) fails to parse due to
> included unitsMLSchema. This does not happen with older Xerces versions
> included in Java 11 -- Java 23.
>
> Is this an Xerces or an Oracle topic?
Did you try it with the official Apache Xerces release? What's the outcome?
> [INFO] Sources are not up-to-date, XJC will be executed.
> [WARNING] RESOLVE External systemId [https://3docx.org/fileadmin/ocx_schema/unitsml/unitsmlSchema_lite-0.9.18.xsd]
> [WARNING] RESOLVE External systemId [http://www.w3.org/2001/xml.xsd]
> [ERROR] Error while parsing schema(s). Location [https://3docx.org/fileadmin/ocx_schema/unitsml/unitsmlSchema_lite-0.9.18.xsd{329,47}].
> org.xml.sax.SAXParseException: src-resolve: Name 'xml:id' kann nicht als 'attribute declaration'-Komponente aufgelöst werden.
> at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException (ErrorHandlerWrapper.java:204)
> at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:135)
> at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:396)
>
> The xmlunits schema looks like this:
> [...]
Looks like some more strict security defaults.
The following appears to work with JDK 21:
public static void main(String[] args) throws Exception {
SchemaFactory sf = SchemaFactory
.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
sf.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
sf.setProperty(XMLConstants.ACCESS_EXTERNAL_SCHEMA, "http,https");
Schema xmlSchema = sf.newSchema(new URL("https://"
+ "raw.githubusercontent.com/OCXStandard/OCX_Schema/"
+ "d9ed9cab9c/ocx/OCX_Schema.xsd"));
System.out.println(xmlSchema);
}
Also using:
sf.setProperty(XMLConstants.ACCESS_EXTERNAL_SCHEMA, "all");
But not with JDK 24, and it seems like a bug to me.
I've tried the following works with JDK 24:
sf.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
sf.setResourceResolver(allowAllResolver());
...
static LSResourceResolver allowAllResolver() {
return (type, namespaceURI, publicId, systemId, baseURI) -> {
System.out.println("type=" + type
+ ", namespaceURI=" + namespaceURI
+ ", publicId=" + publicId
+ ", systemId=" + systemId
+ ", baseURI=" + baseURI);
if (systemId == null) {
return null;
}
return new LSInput() {
@Override public String getSystemId() {
return systemId;
}
@Override public String getPublicId() {
return publicId;
}
@Override public String getBaseURI() {
return baseURI;
}
@Override public Reader getCharacterStream() {
return null;
}
@Override public InputStream getByteStream() {
return null;
}
@Override public String getStringData() {
return null;
}
@Override public String getEncoding() {
return null;
}
@Override public boolean getCertifiedText() {
return false;
}
// Immutable
@Override public void setSystemId(String systemId) {
throw new UnsupportedOperationException();
}
@Override public void setStringData(String stringData) {
throw new UnsupportedOperationException();
}
@Override public void setPublicId(String publicId) {
throw new UnsupportedOperationException();
}
@Override public void setEncoding(String encoding) {
throw new UnsupportedOperationException();
}
@Override
public void setCharacterStream(Reader characterStream) {
throw new UnsupportedOperationException();
}
@Override
public void setCertifiedText(boolean certifiedText) {
throw new UnsupportedOperationException();
}
@Override
public void setByteStream(InputStream byteStream) {
throw new UnsupportedOperationException();
}
@Override public void setBaseURI(String baseURI) {
throw new UnsupportedOperationException();
}
};
};
}
Of course you should not use allowAllResolver() but configure
appropriate CatalogResolver for your runtime.
--
Stanimir