Parsing an XSD with no or a different prefix than xs or xsd fails with a ParsingException

[hschildb]

An XSD file with the below content

<?xml version="1.0" encoding="UTF-8"?>
<xyz:schema xmlns:xyz="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
	<xyz:element name="abc"></xyz:element>
</xyz:schema>

fails with a ParsingException although it uses the correct namespace URI for an XSD.

org.xmlet.xsdparser.xsdelements.exceptions.ParsingException: The top level element of a XSD file should be the xsd:schema node.
        at org.xmlet.xsdparser.core.XsdParser.getSchemaNode(XsdParser.java:128)
        at org.xmlet.xsdparser.core.XsdParser.parseFile(XsdParser.java:97)
        at org.xmlet.xsdparser.core.XsdParser.parse(XsdParser.java:62)
        at org.xmlet.xsdparser.core.XsdParser.<init>(XsdParser.java:38)

whereas the same XSD with a different namespace prefix works:

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
	<xsd:element name="abc">	</xsd:element>
</xsd:schema>

I used the XsdParser v1.2.10.

[lcduarte]

Hello,

The names allowed for the schema node were hardcoded in the XsdParser to either xsd:schema, xs:schema or schema. I've changed it to allow any tag contains schema in the name.

Even with this change you'll need to provide an alternative config if your schema isn't xsd or xs while creating the XsdParser object. Take a look at DefaultParserConfig.

The new version is available 1.2.11.

[hschildb]

Hi Luís,

many thanks for the fast response and the proposed work around. :-)

Your idea to provide an alternative config is good enough if you know upfront (at coding time) that the schema file will use a particular namespace prefix, which differs from the hard coded (de-facto standard) prefixes. However, if that is not the case, for example as schema files with arbitrarily defined prefixes need to be parsed at runtime, the proposal will not work, right?

Or did I miss something?

Best regards,

Holger

[lcduarte]

You are right, in that case it won't work. I haven't really considered the possibility of not knowing the prefixes that will be used.

I might be able to drop the requirement of knowing the prefixes easily if I ignore the prefix altogether while parsing since I think the only use is to determine which parse function will be used for each node of the xsd, and for that the prefix isn't required.

I'll take a closer look into this on the weekend and if I'm able to make the change I'll release a new version.

[lcduarte]

Hello,

I've adjusted the code to support what you've requested. I've released a new version 1.2.12 with the fix.

Let me know if it works for you

[hschildb]

Hi Luís,

thank you, it works for me. The new version now parses XSDs with different prefixes successfully. :-)

Best regards,

Holger