Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

xs:restriction with built-in calendar types as base does not validate #23

Closed
stefanpapp-ape opened this issue May 26, 2020 · 2 comments
Closed

Comments

@stefanpapp-ape
Copy link

Hello,

first of all, thank you for creating this library, it is very appreciated!

Unfortunately though, v1.0.27 seems to have a problem with the validation of xs:maxInclusive if the value is set to one of the built-in calendar types such as xs:date, xs:dateTime or xs:gYearMonth.

I stumbled about this while trying to process one of our schemas (http://www.archivesportaleurope.net/Portal/profiles/eag_2012.xsd). Said schema features a few of xs:maxInclusive declarations, e.g. in lines 176, 181, 186, and 191. When trying to load a local copy of the file via the standard constructor (XsdParser(filepath)), the result was an error with the following stack:

org.xmlet.xsdparser.xsdelements.exceptions.ParsingException: The xsd:maxInclusive value  attribute should be a numeric value.
	at org.xmlet.xsdparser.xsdelements.AttributeValidations.validateDouble(AttributeValidations.java:149)
	at org.xmlet.xsdparser.xsdelements.AttributeValidations.validateRequiredDouble(AttributeValidations.java:163)
	at org.xmlet.xsdparser.xsdelements.xsdrestrictions.XsdDoubleRestrictions.<init>(XsdDoubleRestrictions.java:36)
	at org.xmlet.xsdparser.xsdelements.xsdrestrictions.XsdMaxInclusive.<init>(XsdMaxInclusive.java:24)
	at org.xmlet.xsdparser.xsdelements.xsdrestrictions.XsdMaxInclusive.parse(XsdMaxInclusive.java:34)
	at org.xmlet.xsdparser.xsdelements.XsdAbstractElement.xsdParseSkeleton(XsdAbstractElement.java:158)
	at org.xmlet.xsdparser.xsdelements.XsdRestriction.parse(XsdRestriction.java:118)
	at org.xmlet.xsdparser.xsdelements.XsdAbstractElement.xsdParseSkeleton(XsdAbstractElement.java:158)
	at org.xmlet.xsdparser.xsdelements.XsdSimpleType.parse(XsdSimpleType.java:123)
	at org.xmlet.xsdparser.xsdelements.XsdAbstractElement.xsdParseSkeleton(XsdAbstractElement.java:158)
	at org.xmlet.xsdparser.xsdelements.XsdUnion.parse(XsdUnion.java:57)
	at org.xmlet.xsdparser.xsdelements.XsdAbstractElement.xsdParseSkeleton(XsdAbstractElement.java:158)
	at org.xmlet.xsdparser.xsdelements.XsdSimpleType.parse(XsdSimpleType.java:123)
	at org.xmlet.xsdparser.xsdelements.XsdAbstractElement.xsdParseSkeleton(XsdAbstractElement.java:158)
	at org.xmlet.xsdparser.xsdelements.XsdSchema.parse(XsdSchema.java:108)
	at org.xmlet.xsdparser.core.XsdParser.parseFile(XsdParser.java:100)
	at org.xmlet.xsdparser.core.XsdParser.parse(XsdParser.java:61)
	at org.xmlet.xsdparser.core.XsdParser.<init>(XsdParser.java:37)

It was a bit weird to see the attribute validation classes for Double values being called. Is this because counterparts for calendar values do not yet exist, or is something else to blame?

@lcduarte
Copy link
Member

Hi,

Thanks for using it, and thanks for reporting the issue.

After checking again I did indeed made a mistake while classifying the types of values the restrictions such as xsd:minInclusive, xsd:maxInclusive, xsd:minExclusive and xsd:maxExclusive could have. I'll correct it and release a new version by the end of the week.

@lcduarte
Copy link
Member

Hello again,

I performed a new release to fix it, 1.0.28. If you notice anything else feel free to open another issue :)

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants