XSD 1.1 working

[angelozerr]

XSD 1.1 working

Fixes #363

Signed-off-by: azerr azerr@redhat.com

[angelozerr]

@fbricon I fixed the OutOfMemory with XSD 1.1 which was a problem coming from LSP4XML (an infinite loop). All tests work. If you are OK to merge it, it misses tests:

• test with LSPMessageFormatter because there are no test with LSPMessageFormatter
• test with a sample of validation with XSD 1.1.

If you wish I work today on it, please tell me.

[fbricon]

@angelozerr tests for 1.1 support are needed indeed

[angelozerr]

Ok I will write test today.

[angelozerr]

@angelozerr tests for 1.1 support are needed indeed

Done.

To test this PR, create you a xsd file like this:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema 
	xmlns:xs="http://www.w3.org/2001/XMLSchema" 
	xmlns:t="test" 
	xmlns:vc="http://www.w3.org/2007/XMLSchema-versioning" 
	targetNamespace="test" 
	elementFormDefault="qualified" 
	vc:minVersion="1.0">
	
	<xs:complexType name="testType">
		<xs:all>
			<xs:element name="testEle" minOccurs="1" maxOccurs="unbounded" type="xs:string"/>
			<xs:element name="testEleTwo" type="xs:string"/>
		</xs:all>
	</xs:complexType>
	
</xs:schema>

It's XSD 1.0, you should see the following error:

After that change vc:minVersion attribute with 1.1 like this:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema 
	xmlns:xs="http://www.w3.org/2001/XMLSchema" 
	xmlns:t="test" 
	xmlns:vc="http://www.w3.org/2007/XMLSchema-versioning" 
	targetNamespace="test" 
	elementFormDefault="qualified" 
	vc:minVersion="1.0">
	
	<xs:complexType name="testType">
		<xs:all>
			<xs:element name="testEle" minOccurs="1" maxOccurs="unbounded" type="xs:string"/>
			<xs:element name="testEleTwo" type="xs:string"/>
		</xs:all>
	</xs:complexType>
	
</xs:schema>

The error should gone.

[fbricon]

please update the feature list in the readme

[angelozerr]

@fbricon please don't review this PR. There are some trouble with completion.

[xorye]

@angelozerr Validation with the example you provided works on my end.

I also briefly tested validation with some XSD 1.1 specific features found here: https://blogs.oracle.com/rammenon/xml-schema-11-ndash-what-you-need-to-know and it seems to work correctly (although I am not too knowledgable about XSD).

[NikolasKomonen]

Also tested with some XSD 1.1 stuff. Works for me as well.

[angelozerr]

Also tested with some XSD 1.1 stuff. Works for me as well.

Thank's for your feedback @NikolasKomonen. I need to finish to write tests to accept this PR and if @fbricon is OK.

[deathaxe]

Looks like it needs some work?

[GitMensch]

Could anyone with write access try to fix the conflicts allowing others to test it (for example in the redhat XML plugin)?

It seems the following is far away:

I'm working on this issue with PR #515 It should be available for 0.8.0

Originally posted by @angelozerr in #363 (comment)

Given the issues mentioned in redhat-developer/vscode-xml#222

[mlocati]

So, the reason for holding this PR on is that there isn't a Xerces-with-xsd1.1 version published on Maven, right?

If so, I've contacted the Xerces-J maintainers, and they answered that they won't publish on Maven, but can accept volunteers that do that.

I'm not very familiar with Maven: is there anyone that wants to do that?

[angelozerr]

If so, I've contacted the Xerces-J maintainers, and they answered that they won't publish on Maven, but can accept volunteers that do that.

If I remember @apupier wanted to do that (not sure), but we would like to avoid publishing a non official Xerces XSD 1.1 maven project

[apupier]

If so, I've contacted the Xerces-J maintainers, and they answered that they won't publish on Maven, but can accept volunteers that do that.

If I remember @apupier wanted to do that (not sure), but we would like to avoid publishing a non official Xerces XSD 1.1 maven project

"wanted" is a bit too strong ;-)
I published one version of xerces-j xsd 1.0
I guess I should have rights to publish another version.
if i remember well I didn't published the 1.1 version published because it was never done before and some specific artifacts for it were missing (and I wasn't able to build locally)

[mlocati]

I managed to use the "xsd-1.1" variant of Xerces with Maven without much problems: see https://github.com/concrete5-community/concrete-cif

In particular, here's what I do in order to achieve that:

1. I download the Xerces archive (xsd-1.1 variant) and "install" its jars in the local m2 archive with mvn install:install-file (see here)
2. I reference those packages in my pom file (see here)
3. and finally I'm able to use an XSD 1.1 schema (see here).

[mlocati]

I wasn't able to build locally

@apupier what about asking the j-dev mailing list?

[apupier]

I wasn't able to build locally

@apupier what about asking the j-dev mailing list?

This is anyway not a good way. I should not build an artifact locally and publish it myself. The build needs to be done from a trusted place.
I also do not have time to look deep into this.
You can find what I documented when i published a version here https://issues.apache.org/jira/browse/XERCESJ-1724 and the mention that there was nothing available for xsd 1.1.

[mlocati]

Publishing to Maven seems rather complicated.

But... is it really necessary? Can't we simply install xerces in the local m2 repository like I do in my project?

[mickaelistria]

lemminx-maven is mainly distributed and built as a Maven artifact. Any dependency to a library that is not available in a Maven repository would make it impossible to consume transitively from Maven, because of the missing transitive dependency.
So if lemminx-maven is to use a library that is not published in a Maven repo, then it should consider incuding it in its own Maven repository. As this wouldn't be an official artifact, it should keep the org.eclipse.lemminx groupId.

But overall, the fact that the artifact is not published on Maven with regular Xerces can be interpreted as a sign of immaturity, and do we want lemminx to build on top immature blocks?

I don't think we should aim at a workaround in lemminx, instead, effort should be invested in xerces project directly to make the bundle available. @mlocati As you seem to need it most, you should be the one getting in touch with the xerces support channels and leading the effort of getting the artifact published to Maven. Then we could just use it in lemminx without extra burden.

[mlocati]

But overall, the fact that the artifact is not published on Maven with regular Xerces can be interpreted as a sign of immaturity, and do we want lemminx to build on top immature blocks?

I'd disagree: Xerces is very stable and mature. The problem is simply that the Xerces team doesn't need to publish on Maven.

@mlocati As you seem to need it most, you should be the one getting in touch with the xerces support channels and leading the effort of getting the artifact published to Maven

I play with Java only occasionally, I wouldn't call me an expert: it'd me much better if this task could be done by someone more skilled than be. And Maven is an absolute obscure thing for me.

[irbian]

Hey, just wondering if it has been any advance regarding this, that I understand is the root of why XSLT 3.0 files fail to validate on Eclipse with the message "There are '45' errors in 'schema-for-xslt30.xsd'."

[apupier]

for reference, the ticket asking for a xerces with xml schema 1.1 https://issues.apache.org/jira/browse/XERCESJ-1736