As noted before I think we can just namespace system properties and then we can remove the concept of "reserved properties", wdyt?

Actually we already had namespaced these properties, why did we actually remove them? Was that because of the i18n-namespace? /cc @wachterjohannes @chirimoya

After a discussion with @chirimoya we concluded that we removed the namespace because we already have this i18n-namespace. Actually we don't want to have this namespace at all, so that we could use a sulu-namespace to differ between system and non-system porperties. However, it's not that easy to change anymore...

So what would be your ideal proposition? To have both i18n and sulu namespaces? I would be tempted to have three, sulu, sulu, sulu-data and sulu-data-i18n but @chirimoya raused a valid point about storage capacity.

Magnolia, I think, do not namespace normal "data", and they prefix I18N properties with i18n I think. I forget how they handle system properties, we should have a look.

I would go only with the sulu-prefix, and don't prefix the language separately, since I don't see the advantage of it. But as already said it's not that easy to change anymore...

Well, as you say, if it should be changed we should change it before 1.0 - but we should collect all such changes into as few releases as possible and provide a migration script. There is also a command which allows you to apply a closure to all nodes:

$ php app/console doctrine:phpcr:node:update -q "SELECT * FROM [sulu:content]` --closure="function ($node) { foreach ($node->getProperties() as $property) { ... }"

For example.

If the migration script is quite simple it's maybe an option. @chirimoya WDYT?