It makes sense to me! Thus it will help simplify the Config component and its config tree builder API.

@Haehnchen does the phpstorm plugin use XSD files in relation to bundle configuration, e.g. to suggest keys when typing yaml or something else?

How would you deprecate this without also deprecating other XML uses such as service configuration?

@nicolas-grekas problem is that most (all?) third-party bundles don't provide a XSD for their config ... so the support is of this feature is very limited (just a bunch of official Symfony bundles).

How would you deprecate this without also deprecating other XML uses such as service configuration?

This is not the same part of the code that manage all XML config. Search for XmlFileLoader in the symfony code base.

@Haehnchen does the phpstorm plugin use XSD files in relation to bundle configuration, e.g. to suggest keys when typing yaml or something else?

It uses this file: https://github.com/Haehnchen/idea-php-symfony2-plugin/blob/master/src/resources/symfony2-config.xml

So the answer is ... no.

I know that some companies use XML config files even for bundle configurations (or at least used to be doing it).
@guilhermeblanco I think you were one of the guys using XML there. Is is still the case ?

What would be the benefit?

What would be the benefit?

When we want to add new features / bundle, We have to write the XSD and it's a bit boring.

More over, some features hard to implement in XML, like a "non-validated" part of the XML, like in https://github.com/symfony/symfony/blob/master/src/Symfony/Bundle/FrameworkBundle/Tests/DependencyInjection/Fixtures/xml/workflow_with_arguments_and_service.xml#L12-L13 . In the case of the Workflow, it's not that hard, because arguments don't have a key (this is a list, not a map).

And Finally, I will reduce the codebase, issues, support etc.

I understand the motivation but I don't think it's nocive to keep it.
Nobody forces you to provide an XSD schema for your 3rd party bundles. If you provide it, then that's great for people favouring xml (apparently there are lexik/LexikJWTAuthenticationBundle#308). If you don't then at worst you'll lose them, at best one will contribute it.

@stof yes, it is still my preferred method of configuration. Deprecating yaml makes much more sense to me than xml.
Xml and a decent ide provides you an easier way to validate your configuration and autocomplete, without suffering of errors at line 0, col 0 like yaml.

For your interest (@fabien should get a notification on this too), we already removed yaml support from Doctrine ORM 3 (branch develop).

you will almost not simplify the Config Definition component if we drop XML support:

• useAttributeAsKey cannot disappear, as it has 2 purposes: it marks the prototyped array node as a map rather than a sequence, and it configures the XML attribute storing the map key. So the argument is relevant for XML only, but the call is relevant for everyone (there is a bug allowing to keep existing keys from YAML without this call when no merging is involved, but I want to deprecate this in 3.4 as this only allows to hide mistakes breaking configs when a user tries to overwrite the config in a different file and suddently getting a sequence for real)
• fixXmlConfig remapping prototyped array nodes to handle the fact that XML tags generally use a singular name and (most importantly, even though the usage of singular is what allowed us to fix this easily) that the parsing does not produce an array of children when there is a single child

Only fixXmlConfig could disappear if we drop support for XML in the Config component. And I don't think this is worth it in term of maintenance.

The only hard part to implement in XML config files are places where you use variableNode in your config tree to allow unvalidated configuration (because XML is still quite strict).

One thing I'd like to experiment with is a validator class checking for places in a config tree which are likely to miss support for XML config files, to make it easier for bundles to avoid forgetting to support it (they could run this validator in a unit test of their Configuration class)

@guilhermeblanco some of us think that removing YAML support in Doctrine is a BIG mistake.

YAML is the most downloaded PECL package (it has ~24 million downloads and the second package has ~7 million: see stats).

YAML is the 3rd most popular Symfony component (~48 million downloads, second only to EventDispatcher and Console: see stats).

YAML is ubiquitous and most of us use it.

@javiereguiluz I think annotations are much more common for Doctrine mapping than YAML (and actually, some features were buggy in the YAML driver during a long time)

@stof do you know the reason behind the dropping of YAML in Doctrine, besides its lack of usage?

@tgalopin: Well for one it's hard to write. xml with xsd and good IDE that suppots xsds wins each time.
I do agree that xml is more verbose, but autocomplete wins.

PHPStorm does support YAML autocompletion, I don't think this really matters.

In my opinion, dropping XML in the case of Symfony config is as coherent as dropping Doctrine YAML in metadata: it decreases the need of maintenance for something used by a really small percentage of developers.

@tgalopin except for the XSD (which is optional when supporting XML), there is not that much maintenance for the support of XML: the Config component handles all the normalization we need to handle difference between XML and YAML files (and very few of it can be simplified if we drop XML support, as said previously). And the code loading the extension config in the XML loader has not changed at all since at least Symfony 2.3 IIRC, meaning the maintenance cost for it is very small (the code works fine, and we never needed to add new features at this layer)

Actually, I opened this RFC because I had to update the .xsd (and tests) for the workflow and now I might work on a new component / bundle and I have to updated it again. And I just feel it's a waste of time because nobody is using it :/

And finally, xml does not support random arbitrary section :/

@lyrixx several people in this thread already said they are using XML config files. And only a few people were involved. So because nobody is using it is wrong. It is only true if you alter it to because nobody @lyrixx knows is using it, but then it does not justify removal anymore (unless you know the whole community)

Hehe. Indeed. Or I could say: "Almost nobody is using it". And as far as I see, only @guilhermeblanco is using it.

Also, we can consider theses stats:

• 77 project for XML: https://github.com/search?utf8=%E2%9C%93&q=extension%3Axml+path%3Aapp%2Fconfig+framework&type=Code
• 155,811 project for YAML: https://github.com/search?utf8=%E2%9C%93&q=extension%3Ayml+path%3Aapp%2Fconfig+framework&type=Code

this only searches in public Github projects. This misses lots of Symfony projects.

However, I never argued that YAML is not by far the most common format for the semantic config of bundles (it indeed is, which is also why we display it first in the doc). But I don't think it justifies the removal.

@nicolas-grekas PhpStorm plugin does not use XSD files

some of us think that removing YAML support in Doctrine is a BIG mistake.

The Doctrine YAML driver wasn't as advanced as the Symfony Config component, one space could ruin your day and you would never get a proper error because nothing was strictly validated.

YAML is great for simple configurations IF you have strict validation, else it's going to hurt bad one day...

@sstok the problem is that Doctrine follows convention over configuration, and mostly we cannot validate the arguments because they'd become required. That breaks the cycle and enforces us to remove all validation.

This misses lots of SF projects, but still can give us overview of the usage : 0.04% ...

Would this disallow me to do import service definitions from an XML file in config.yml like this?

imports:
    - { resource: services.xml }

If no, I don't care much. If yes, I'd object. I see the combination config.yml + services.xml quite often in projects.

@derrabus No. You will still be able to import service in XML ;)

@guilhermeblanco some of us think that removing YAML support in Doctrine is a BIG mistake.

That moment you learn that doctrine will not support yaml and you have to migrate dozens of projects in the future... from a "week of symfony" link...

I believe there is a Doctrine command to convert mapping from one format to the other 🤔
Can't check, because I'm not using Doctrine 😝

@sstok, converting mappings is not a problem. changing 20 developers minds is. we generally are not using annotations for entitties (imagine entity with doctrine, jms and validation annotations altogether), so the left option is xml. converting from yaml to xml is a kind of downgrading for me, especially with the fact that we do not have any other xml configs in our projects.

There are many 👍 from the community. What Do @symfony/deciders think ?

I wouldn't touch an XML file with a ten foot pole ... but I'd say, let's keep it.

Third-party bundles are smart enough to already ignore XML config entirely ... so this only affects to Symfony core itself. I know that creating these XML files is awfully boring, but the maintenance it's not as bad, so it shouldn't be that much work for us (for you in the case of the Workflow 😄 ).

My fear is that if we remove this, Symfony will no longer fully support XML. Instead of saying "Symfony supports XML, PHP or YAML for the config" we should say "Symfony supports PHP and YAML for config ... and XML most of the times, but not always".

I still don't get why we should remove support. That's a clear 👎 from me.

Ok Let's close this ;)
I already updated the XSD anyway.