First, I do not like anything with the name "EDL" because that has the baggage of being confused with the non-standardized file format known as "EDL" not to mention completely different things like mplayer EDL.

Secondly, is it realistic to do anything more than simple cut lists? What about audio and image processing effects? If you want to include that do you specify every possible effect and parameter in this file specification? If not, then apps will need to agree to use the same effect implementations and agree how parameters are serialized. What does that portend for keyframable effects? That area is a big problem - a rabbit hole with huge risk that nothing is ever achieved. 

With MLT, there is one framework, one domain of possible effects, and an out-of-the box XML (de)serialization. And even none of those apps can edit each other's projects - at the most, include the others' as a virtual clip. Why? Even with all that the framework provides, including constraints, it is difficult. And that would be on top of already very difficult work by small teams working part time. I do have near term plans to make Shotcut interoperate better with Kdenlive MLT XML.

So, how about just a simple cut list? Kino used SMIL for that. I made MLT read Kino's SMIL files (smil, seq, and video elements only), but today that only lets MLT apps load SMIL as a virtual clip. It would only take a little effort to let Kdenlive and Shotcut import a SMIL playlist as an editable project. A bit work for Flowblade since it does read MLT XML today - only export.

SMIL is perhaps not the best choice since it can do so much more. Is there another text-based standard for simple cut lists that can or should be considered? Or, perhaps, it is reasonable to go beyond simple cut lists and have multitrack cut lists (but still no effects). And then SMIL with "par" element makes more sense.

SMIL3-Tiny+MediaClipping is an established open standard for a multi-track cut list:
http://www.w3.org/TR/2008/REC-SMIL3-20081201/smil-tiny-profile.html

I suggest to ask others - projects, developers, power artists - their thoughts on supporting that. If not, how about a JSON version of a simpler version of that (e.g., fewer time value formats, minus animation and text media elements).

(In reply to Dan Dennedy from comment #1)
> First, I do not like anything with the name "EDL" because that has the
> baggage of being confused with the non-standardized file format known as
> "EDL" not to mention completely different things like mplayer EDL.

good point.

> 
> Secondly, is it realistic to do anything more than simple cut lists? What
> about audio and image processing effects? 

for me, we could start with a cut list and simple a/v transitions (fade-in/fade-out). imo, effects, audio and color grading should be done in a latter stage of the workflow, although some people would prefer to have effects as well.

> If you want to include that do you specify every possible effect and 
> parameter in this file specification? If not, then apps will need to agree to > use the same effect implementations and agree how parameters are serialized. > What does that portend for keyframable effects? That area is a big problem - > a rabbit hole with huge risk that nothing is ever achieved. 
  
the latter would be better right? as for keyframes we have to think about it more. 

> difficult. And that would be on top of already very difficult work by small
> teams working part time. I do have near term plans to make Shotcut
> interoperate better with Kdenlive MLT XML.

Check out this project, it just launched and attained nearly 50% in 2 days:
https://www.indiegogo.com/projects/mox-file-format/

There seems to be interest in interoperability and cross platform standards in the industry. We could also try to raise funds to pay a team to make it happen. 

> 
> So, how about just a simple cut list? Kino used SMIL for that. I made MLT
> read Kino's SMIL files (smil, seq, and video elements only), but today that
> only lets MLT apps load SMIL as a virtual clip. It would only take a little
> effort to let Kdenlive and Shotcut import a SMIL playlist as an editable
> project. A bit work for Flowblade since it does read MLT XML today - only
> export.

it would be great to have shotcut, kdenlive and flowblade work together since they all use mlt.

Please discuss this on mailing lists; in general, we do not incubate projects from the get-go, but look to take projects which have traction already from multiple projects and some established code to work with. Once you have that for your project, we can look at hosting.