[RFC] Deprecate and remove support for semantic XML configuration

[lyrixx]

trafficstars

Description

Maintaining https://github.com/symfony/symfony/blob/7.3/src/Symfony/Bundle/FrameworkBundle/Resources/config/schema/symfony-1.0.xsd is not easy. And I never saw a project using XML to configure the framework.

So I propose to remove this support. I know it's always heartbreaking to remove a feature, but I really think it's much better for Symfony maintainers.

More over, we now have much better format to configure the framework...

Example

No response

[lyrixx]

maybe it can be generated from the Configuration definition?

What do you mean by "it"?

deprecating format X can be really painful for (some) users, im not sure it's generally worth it, since it's just format X

I agree but I really didn't see any project using it. More over, this configuration formation is painful to use (event for end user)

And Doctrine has already removed a configuration format. So there is a precedent 😃

[GromNaN]

maybe it can be generated from the Configuration definition?

This is not trivial as there is some transformations of the input before validating the configuration (example in DoctrineBundle) that requires a specific schema file. We hit this issue while trying to generate the JSON schema configuration in https://github.com/symfony/symfony/pull/59620

And I never saw a project using XML to configure the framework.

~We can decide to deprecate this format and possibly reconsider this decision before deleting it, if people contest with specific use cases.~ Let's try to gather feedback before committing the deprecation.

[lyrixx]

maybe do some public polls first?

I'd like to, but I don't know where we could put it to reach the maximum number of people.

[wkania]

I'd like to, but I don't know where we could put it to reach the maximum number of people.

During https://live.symfony.com/

[stof]

I think there is 2 different cases here:

• XML support for the semantic configuration of bundles (which can be quite complex to handle as it is dynamic, and most non-core bundles don't care about providing an XSD)
• XML support for Symfony configuration files (service definitions, routes, etc...), for which the XSD is quite straightforward

I know that some projects use XML files for the second case (the XSD provides better IDE support that for Yaml files for instance). I'm not sure it is worth deprecating those.

[stof]

Reading the issue again, I see that it proposes only the deprecation of the first case. I got confused by #60568 that deprecates everything about XML when claiming to fix this issue.

[nicolas-grekas]

I'm in favor of dropping everything XML-related. Json-schema & array-shapes to the rescue instead of XSD if we want to provide an alternative IMHO.

[GromNaN]

Using XML for services and routes definition has been the dominant practice in popular bundles.

• Sulu: https://github.com/sulu/sulu/blob/2.6/src/Sulu/Bundle/MarkupBundle/Resources/config/services.xml
• API Platform: https://github.com/api-platform/core/tree/4.1/src/Symfony/Bundle/Resources/config

Let's focus on semantic configuration first, which is much more rarely (if ever) used.

[nicolas-grekas]

Sure, that's why we need to deprecate first, then remove as usual. Keeping part of the xml stuff wouldn't allow us to remove any code, making the effort worthless. On the contrary, sending a message to bundles that they should move to php config is desirable - the format exists long enough.

[lyrixx]

Let's focus on semantic configuration first, which is much more rarely (if ever) used.

I would start with this first 👍🏼

Keeping part of the xml stuff wouldn't allow us to remove any code

No, we well be able to drop some code!

• In the Configuration class
  • there are lots of workarround to support XML
  • fixXmlConfig()
• My nemesis : https://github.com/symfony/symfony/blob/7.4/src/Symfony/Bundle/FrameworkBundle/Resources/config/schema/symfony-1.0.xsd (well, actually I'm not okay with XSD 🤓)
• many fixtures, tests, etc

[nicolas-grekas]

Not sure what y'all mean by "first": maintaining XML loaders for 5 more years in 8.x cycle? Better not!

[lyrixx]

héhé, just to clarify : I don't like to maintain XML support in semantic configuration. I don't really maintain routing & service configuration. That's why I wanted to remove only semantic configuration.

But if we all agree to drop all XML configuration, I'm obviously okay with that!

[alexander-schranz]

This discussion is a little bit unclear in what direction this is going and what the question is to the community?

Are you try to get rid of XML schema for Core Bundles (Framework, Security)? Or do you want to remove the whole XML support in the symfony dependency-injection/http-kernel/config components?

---

I want to give a little bit insights how we use XML in @sulu. Sulu core uses in most bundles which where created the last years xml for the service definition. We are try to get rid of them by step by step upgrading older bundles to PHP based configuration so the service definitions is no issue for us.

I also think the doctrine orm.xml are not part of this discussion so they will stay.

---

Still @sulu uses in other places XMLs, the most common uses are templates and webspace beside forms and lists configurations. This is very Sulu specific things and currently the xml are not build with symfony bundle configuration, but the community of Sulu did request it in some special cases to use PHP and so it was kind of planned currently to migrate the whole webspace and template configurations from custom loaders to bundle configurations (open PR).

Most people will question here:

Why is XML even relevant still here in Sulu if Yaml or PHP is supported?

You need to understand here what kind of developers work on Sulu projects. There are big companies, where the developing process are split in frontend and backend work. And I mean even that kind of frontend teams who never writes a single line of PHP code.

Webspaces and Templates configuration in Sulu need and are tackled by the Frontend Teams for creating the content structure for there created design and here is why @sulu decided to go with XML. What are Frontend Developers most familiar with? It is HTML and so the nearest neighbor to it is XML. Yaml and PHP would not be an option for this teams and would be more edge cases where people want to build complex logics. And so Sulu default configuration for webspaces and templates even today still planned to be XML even if it would be changed to be a bundle configuration.

---

So from Sulu perspective:

• Remove Symfony core Bundle XML Support: ✅
  • (Sulu skeleton uses still yaml for symfony core bundle configurations)
• Remove service definitions via XML Support: ✅
  • (needs some work but doesn't effect endconsumer of Sulu so fine)
• Remove general Bundle configuration via XML Support: 🟡
  • (would require to change our plans as it would be a nogo for our templates and webspace configurations)

I hope I could give you a good overview where we use XML and why. As it effects directly our plans and we would need to skip some plans like converting existing custom loaders to symfony bundle configuration, it would be really good to know in which direction Symfony goes. As we realising soon a new Major which will be supported over the next years.