YAML simplification

--===============0641214620807051410==
Content-Type: multipart/alternative; boundary="94eb2c08bb0ca6d85b0566956b51"

--94eb2c08bb0ca6d85b0566956b51
Content-Type: text/plain; charset="UTF-8"

Hi all,
I see 2 major directions for YAML evolution:

1. radical simplification
2. more features

The advantages of the first:
a) easy adoption
b) rock solid spec - because there is nothing to change like in JSON
c) no need to mention version (1.1, 1.2. 1.3, 2.0 etc)
d) we can drop %YAML directive because all the versions are supposed to be
the same

I do not claim that simplification does not have disadvantages but does
make YAML more user friendly.

(who complains that boolean has 2 values instead of 18 ? )

I would like to vote to the features which can and should be dropped:

1. all the implicit types except the ones from JSON (users should be able
to define custom implicit types) Recommended Schema_s_ should become
Schem_a_
2. Complex keys (let us allow JavaScript to implement the spec). No need to
discuss the 1024 limit
3. Folded scalar
4. Chomping indicators
5. Indentation indicators (who is using it and why?)
6. Directives


Feel free to add your vision here.

Cheers,
Andrey
SnakeYAML developer

P.S. I fully support proposals (https://github.com/yaml/yaml-spec/wiki)
which make YAML  stricter.

--94eb2c08bb0ca6d85b0566956b51
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div><div><div><div><div><div><div><di=
v><div><div><div><div><div>Hi all,<br></div></div>I see 2 major directions =
for YAML evolution:<br><br></div>1. radical simplification<br></div>2. more=
 features<br><br></div>The advantages of the first:<br></div>a) easy adopti=
on <br></div>b) rock solid spec - because there is nothing to change like i=
n JSON<br></div><div>c) no need to mention version (1.1, 1.2. 1.3, 2.0 etc)=
<br></div>d) we can drop %YAML directive because all the versions are suppo=
sed to be the same<br><br>I do not claim that simplification does not have =
disadvantages but does make YAML more user friendly.<br><br></div><div>(who=
 complains that boolean has 2 values instead of 18 ? )<br><br></div><div>I =
would like to vote to the features which can and should be dropped:<br><br>=
</div><div>1.
 all the implicit types except the ones from JSON (users should be able=20
to define custom implicit types) Recommended Schema_s_ should become=20
Schem_a_<br></div><div>2. Complex keys (let us allow JavaScript to implemen=
t the spec). No need to discuss the 1024 limit<br></div><div>3. Folded scal=
ar<br></div><div>4. Chomping indicators<br></div><div>5. Indentation indica=
tors (who is using it and why?)<br></div><div>6. Directives<br><br><br></di=
v><div>Feel free to add your vision here.<br><br></div><div>Cheers,<br></di=
v><div>Andrey<br></div><div>SnakeYAML developer<br><br></div><div>P.S. I fu=
lly support proposals (<a href=3D"https://github.com/yaml/yaml-spec/wiki" t=
arget=3D"_blank">https://github.com/yaml/yaml-<wbr>spec/wiki</a>) which mak=
e YAML=C2=A0 stricter.<div class=3D"gmail-yj6qo"></div><div class=3D"gmail-=
adL"><br></div></div></div></div></div></div></div></div></div></div><br></=
div>

--94eb2c08bb0ca6d85b0566956b51--


--===============0641214620807051410==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--===============0641214620807051410==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Yaml-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/yaml-core

--===============0641214620807051410==--