Skip to content

Schema binding by file association with variable works only for active file #629

Closed

Description

@stphnrssr

Hello,
I'm struggling with file association binding of xml schema.
Consider the following data (all files provided in attached test.zip):

  • 2 xml files named data1.xml and data2.xml
  • 2 matching schemas data1.xsd and data2.xsd
  • binding is provided by file association in VS Code settings as follows:
    "xml.fileAssociations": [
        {
            "pattern": "data*.xml",
            "systemId": "${fileBasenameNoExtension}.xsd"
        }
     ]

Now, xml validation works fine for each file individually, but problems are systematically reported for other files:

Selecting data1.xml, it shows that everything is ok in that one, which is correct. But at the same time, in the Problems panel, an error is reported for data2.xml
image

Same behavior - reversed - when selecting data2.xml:
image

And when another file is selected, e.g. settings.json, then errors are reported in both xml files:
image

The problem is, that the predefined variable ${fileBasenameNoExtension} points to the current active file. Consequently the validation schema is selected on the basis of the active file, and that schema is applied to all validated files, which produces wrong validation results.

Would there be a way to correctly retrieve the name of the validated file instead of the name of the active file?

Note: at the moment, I'm generating explicit bindings for each individual file (no predefined variable). Not very elegant, but it works fine in all cases. The thing is, my real dataset is much more elaborate than that simple example, and explicit binding of each file generates a pretty large workspace configuration file.

Activity

  1. angelozerr commented on Dec 22, 2021

    @angelozerr
    Contributor

    Indeed there is a problem with fileBasenameNoExtension. We update fileBasenameNoExtension file associations on XML Language Server side for the activated file editor. With your usecase it's indeed unusable.

    We need to improve it but Idon't knowwhen we could do that.

  2. self-assigned this
    on Oct 16, 2026
  3. added this to the 0.30.0 milestone on Oct 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions