Nicolas De loof

yes, that's the idea. On the other hand, letting this be any string could be used to let implementation support alternate values. I can imagine for sample that `isolation` which...

the docker-compose implementation is highly legacy (links were used before introduction of docker networks). I agree defining support for an explicit `[container:|service:]ref` would make sense.

Would be nice we get a script/automation to generate this ToC

> The official recommended [filename extension](https://en.wikipedia.org/wiki/Filename_extension) for YAML files has been .yaml since 2006.[[12]](https://en.wikipedia.org/wiki/YAML#cite_note-12) That's being said that's just a way for us to define order for searching files on...

imho we should keep ports.mode as a legacy attribute and better express such things by routing rules (see https://github.com/compose-spec/compose-spec/issues/111)

The Compose Specification is expected to be generic, so allowing use of `service:xx` with platform to provide some service lookup mechanism is still relevant, while I understand we also need...

env file support by compose-spec is inherited by docker-compose's python codebase so format is set by https://pypi.org/project/python-dotenv/ I'm not sure about quotes support there, but for compatibility with existing compose...

Right, if we can't find a reasonable reference for dot env file format, we could include this in the compose-spec. imho this would make sense to create de dedicated page...

maybe we should just not include labels in the spec. Implementation can track resources using an alternative platform mechanism

> it will still be breaking change. There's many places we have both a "short syntax" and "long syntax", so we could both support the existing syntax: ```yaml env_file: -...