Add Basic XML Syntax Validation

[DotJoshJohnson]

Description Users should be able to enable a feature that would display an error/warning on format if an XML document is not well-formed.

Related: #158

[angelozerr]

Please try redhat.vscode-xml which provides this validation feature:

[bd82]

Does the xmldom library used in this vscode extension not provide syntax validations?

If you have parsing requirements for XML specifically for editor tooling infrastructure This may be of help:

• https://github.com/SAP/chevrotain/blob/master/examples/grammars/xml/xml.js

[bmix]

Please try redhat.vscode-xml

Are they compatible? I had that installed alongside this project, but when I hit CTRL+SPACE the cursor jumps to the beginning of the document.

[bd82]

I have been doing some work on XML Language Services here:

• https://github.com/SAP/xml-tools

You could use the xml-tools/parser package to get syntax errors.

• https://github.com/SAP/xml-tools/tree/master/packages/parser

There are additional capabilities in that mono-repo that may be useful for a VSCode XML extension, feedback is welcome :)

[bd82]

Hello again.

The npm package I mentioned above for Syntax Validations is available as part of the XML-Toolkit VSCode Extension now.

• https://marketplace.visualstudio.com/items?itemName=SAPOSS.xml-toolkit

@DotJoshJohnson: If you are interested in integrating this into your XML-Tools extension, see example here:

• https://github.com/SAP/xml-tools/blob/master/packages/language-server/lib/language-services.js#L47-L57
• Note this is a pure JavaScript implementation, no need for Java or another runtime.
• Also note that this is wrapped with a Language Server which is likely overkill for such a limited scenario, I guess vscode.languages.* should have APIs to directly expose diagnostics without running a Language Server.

[bd82]

P.S the Prettier XML Plugin also uses the @xml-tools/parser npm package.

Perhaps this Prettier Plugin (formatter) is of interest as an alternative to implementing an XML Formatter From scratch in this extension.

[angelozerr]

Note this is a pure JavaScript implementation, no need for Java or another runtime.

@bd82 you are speaking about vscode-xml from Red Hat which required Java, but now vscode-xml 0.15.0 from Red Hat no longer require Java.

[bd82]

Hello. @angelozerr.

My concern with Java was not the Java runtime itself, but rather the resources consumption of the extension. This new extension has a "binary" version with the compiled (JAVA) artifacts running without any need for the Java Runtime. What I do not know are what is is resource consumption of this "binary" version? Is it similar to the Java (none compiled) version?

[angelozerr]

My concern with Java was not the Java runtime itself, but rather the resources consumption of the extension.

Ok I see, have you some usecase with resources consumption ?

This new extension has a "binary" version with the compiled (JAVA) artifacts running without any need for the Java Runtime. What I do not know are what is is resource consumption of this "binary" version?

We decide to provide a binary support (created from Java sources) because all bad issues was about this Java requirement. See https://github.com/redhat-developer/vscode-xml/blob/master/docs/Preferences.md#server-binary-mode for more information.

But to be honnest with you, I don't know about resource consumption with binary support (I had not this problem on my local laptop with resource consumption, so I'm waiting for usecases to investigate problems)

Is it similar to the Java (none compiled) version?

Yes it's exactly the same feature for Java and binary.

[bd82]

Ok I see, have you some usecase with resources consumption ?

Yeah, when the dev env is a container in the cloud, e.g: https://www.gitpod.io

[rgrunber]

The binary (generated with graalvm native-image tooling) should generally perform better on initial startup and offer a lower memory footprint. See https://dzone.com/articles/profiling-native-images-in-java for a brief overview.

It might be nice to try such experiments on vscode-xml, but there's also some articles out there that seem to come to the same conclusion : https://www.inner-product.com/posts/benchmarking-graalvm-native-image/ .

In cases where one needs to use vscode-xml through a java runtime, there may still be some memory performance improvements that can be done. As an example, see : https://github.com/redhat-developer/vscode-java/pull/1262 .

[bd82]

Thanks for the detailed information @rgrunber and references 👍