Investigate better alternatives for encode() / decode() functionality

Further, those might need to be able to parse attributes (at least of the language as I heard).

I'm trying to get caught up on this initiative, so I'm sorry if this is addressed elsewhere. What is the reasoning behind using XML for storage rather than just JSON? Drupal already has decent JSON encode/decode support.

I found this array-to-domdocument library which might be of value. Here are a few notes:

• It uses DOM instead of SimpleXML
• Supports attributes
• Found it in this discussion: http://www.devexp.eu/2009/04/11/php-domdocument-convert-array-to-xml/
• A sandboxed project in contrib uses it for generating a WSDL/WADL file of a Drupal app, Services Docs.
• MIT license

@rwohleb: Here you go -> Configuration management sprint - file formats && File format discussion continued

There is nothing to gain from XML given those constraints. If you want XML anyway, you can use some standard key/value DTD, like the Apple Property List format, that should be supported by most IDE out there.

One additional question that has not been a big focus yet is the question of the mergeability. None of the serialization formats (JSON, XML, PHP) that have been suggesting have good mergeability. If you have already worked collaboratively using the Features module (to export Views, Panels, Fields, etc.) you probably already bumped into this issue: none of the common VCS and IDE out there now how to reasonably merge this type of files, because you need more then the standard line-based merge technique (see A State-of-the-Art Survey on Software Merging by T Mens for an overview of merge techniques).

This is going to be even more a problem if we package all the configuration using the same format. Not completely sure what the solution is at this point, but it is a discussion really worth having.

My guess is that any machine/serialization oriented configuration format won't be easily mergeable if it has not been created with human readability in mind.

Best format ever for this is plain good old ini file, or eventually YAML.

Human readability and machine mergeability are two independent concepts.

The main mergeability issue we currently have with structured text format (pretty JSON, pretty XML, YAML) is that the tree structure is not represented in each line, so the merge tool is going to try to merge independent parts of the tree.

Typical example: two developers are adding a different field to a View; instead of adding those below each other, a line-based merge tool is going to try to merge them, because some of the lines are common in those blocks.

One way of fixing that would be to materialize the whole tree path at every line.

Human readability and machine mergeability are two independent concepts.

While they are indeed two different concepts in real life pretty much all merge algorithms (at least those we use everyday, git, svn, diff, etc..) are merging on a per line basis: pretty much the same way you format your own code to make it human readable.

While they are indeed two different concepts in real life pretty much all merge algorithms (at least those we use everyday, git, svn, diff, etc..) are merging on a per line basis: pretty much the same way you format your own code to make it human readable.

Not exactly: human readability is often necessary for line-merging algorithms, but it is *far* from sufficient.

Yes of course, but this plays its role. Most common diff algorithm is LCS (longuest common subsequence) and it definitely plays very well with human readable text, probably a lot more than any compiled binary (or not) data. We can consider XML being almost binary when you compile it with no pretty formatting, and considering the order doesn't matter.

What about ASN.1 ? There is a PHP library for it, the format is standardized, and the language is made to define rules and structure, which is what configuration is.

Just a wild idea, though.

P.S. : sorry for being somehow off-topic, I couldn't find anywhere else to post this idea.

#4 looks interesting.
That said, I've always preferred JSON over XML (and didn't think the "_comment" convention was a bad idea back in the original discussions).
Still, it's partially-irrational (as with everyone when XML is discussed), so I haven't felt the need to jump into the holy wars until now.

I don't really understand what we get with xml or json that we don't already have with php.

- any drupal user knows php
- php files are protected by the webserver
- php files are quick to parse
- php files are even quicker to parse when there is an opcode cache like apc
- php files (arrays) are quick to merge in php
- php files can be made easy to merge by a machine, look at this :

// this is the recent content view config code updated by bob on 12/01/02
// ^^^^^ look, comments !
$config['view']['recent_content']['title'] = 'Recent content view title';
$config['view']['recent_content']['title']['fr'] = 'Contenu récent'; // note this could come from another file
$config['view']['recent_content']['handler']['display']['fields']['title']['id'] = 'title';
$config['view']['recent_content']['handler']['display']['fields']['title']['table'] = 'node';
$config['view']['recent_content']['handler']['display']['fields']['title']['field'] = 'title';
$config['view']['recent_content']['handler']['display']['fields']['title']['label'] = 'Title';
// [...]

Php is so anchored in Drupal, that my config is even hightlighted (in color) in this comment :-)

I really don't see the point of using a file format that at the end, you will need to convert to a php array, instead of directly using a php array.

Using xml <-> array = impedance mismatch = developer nightmare

PHP cannot be taken out of memory, ever, so it leaks memory.
PHP is a potential security attack vector.
PHP is not as human editable as you might think.

Point 1 is the deal killer. The other two are just icing. PHP was rejected months ago for good reason. Let's please not reopen that debate.

Additional datapoints: Composer users JSON, and there's discussion of using Composer in core. However, Fabien from Symfony noted this weekend that he hates JSON as a config format (mostly due to the stupid trailing comma issue), and wondered why we were using XML without a schema. Of course his preference is YAML, which we also already rejected. :-)

Take those data points as you will.

@hejrocker I think philippejadin was not talking about *serialized* PHP but about plain good old PHP files.

I've seen the discussions about config formats. Sorry for reopening this, coming late to the discussion.

I have to say it, just because I have gone this way a long time ago (xml vs json vs php vs xyz), and it has been a very painful ride.

The fact that xml converted to php arrays creates ugly structures should be taken as a fact.

Here is what I came to in 2006 for my home made cms (later I switched to Drupal ;-) ) :

- http://svn.berlios.de/wsvn/thinkedit/trunk/config/tables-dist.php
- http://svn.berlios.de/wsvn/thinkedit/trunk/config/sample_config/yapaka.php

I can tell you that it was very easy to use, parse, even for a non developer. Please take it into account too.

I stop there, because, I guess there is a bigger picture I probably don't understand.
This config initiative is in all cases a great thing for drupal. I hope module developers (views for example) will use it!

I feel guilty for re-questionning the choice of xml.

Taking xml as granted, I came to the same conclusions as #5 about atributes.

My (2006) implementation is still here : http://svn.berlios.de/wsvn/thinkedit/trunk/class/xml_parser.class.php

The battle plan was to limit features :

- no attributes
- only one element of the same name at the same level
- if more than one element, use "id" attribute to differentiate them

I believe, due to http://www.heyrocker.com/node/238 and http://www.heyrocker.com/how-use-drupal-8-configuration-system, this can be closed.

Updating description to link to heyrocker's status update in mid-March 2012.

I don't believe so. The need for a better encode/decode system is still present. heyrocker, feel free to correct me and re-close. :-)

#1470824: XML encoder can only handle a small subset of PHP arrays, so switch to YAML

Adding another link.