Re: YAML 1.2/1.* vs YAML 2.0

DWIM is tricky...

    null: #This is a comment

vs.

    color: #ff00ff

For example. We tried a rule saying # only starts a comment if it is
followed by white space (or the end of a line, or the end of a file). That
turned out not to be DWIM either...

Or take starting text with a [

   not-an-array: [1,2,3] with some extra attached

What is the DWIM here?

It seems to be a "damned if you do, damned if you don't" situation :-(


On Thu, Mar 3, 2016 at 10:29 PM, Brad Baxter <[email protected]> wrote:

> along these lines ...
> > There are probably other proposals along these lines. We should spend
> some
> > time actively polling people for ideas. "What is your least favorite part
> > of YAML, and how would you fix it".
>
> I'll revisit some examples (from 10 years ago):
>
> ---
> color: #c0c0c0
> title: Hanna Reitsch: Hitler's Female Test Pilot
> chapter: 1[tab]Aviation
> ...
>
> ---
> Creator: Baldowski, Clifford H., 1917-
> Title: You crazy communist! You trying to get us all killed?, [1962].
> Online Publisher: [Athens, Ga.] : Digital Library of Georgia, 2002
> Original Material: Savannah, Ga. : Commercial Lithograph & Printing Co.,
> 1917
> ...
>
> Feeding these into http://ben-kiki.org/ypaste/ seems to indicate that
> some of them are DWIM, while others are not.
>
> In short, in an "ini" format (speaking loosely), the above might look like
> this:
>
> [1]
> color: #c0c0c0
> title: Hanna Reitsch: Hitler's Female Test Pilot
> chapter: 1[tab]Aviation
>
> [2]
> Creator: Baldowski, Clifford H., 1917-
> Title: You crazy communist! You trying to get us all killed?, [1962].
> Online Publisher: [Athens, Ga.] : Digital Library of Georgia, 2002
> Original Material: Savannah, Ga. : Commercial Lithograph & Printing Co.,
> 1917
>
> and on each line, everything from the first colon to the newline is
> the value of the key preceding the colon.  YAML doesn't do this for
> reasons that require some knowledge of the YAML specs.  Getting this
> to consistently DWIM in YAML is easiest fixed by requiring quotes,
> e.g.,
>
> ---
> color: "#c0c0c0"
> title: "Hanna Reitsch: Hitler's Female Test Pilot"
> chapter: "1[tab]Aviation"
> ...
>
> ---
> Creator: "Baldowski, Clifford H., 1917-"
> Title: "You crazy communist! You trying to get us all killed?, [1962]."
> Online Publisher: "[Athens, Ga.] : Digital Library of Georgia, 2002"
> Original Material: "Savannah, Ga. : Commercial Lithograph & Printing Co.,
> 1917"
> ...
>
> But in that case, it's easy to say, "Well then, why not just use
> JSON", which has arguably a shallower learning curve.
>
> I'm saying all this in the spirit of, "What is your least favorite
> part of YAML", which for me is the fact that one of the goals of YAML
> is *not*:
>
> YAML documents are easily writable by humans.
>
> Because, I'm sorry, they are not.  :-)
>
> The second part of the above quote is, "and how would you fix it"
>
> Honestly, I don't know.  Maybe an iYAML profile (Apple be damned)?  Or
> maybe eYAML would handle this?
>
> Since I first brought this up, I've been using an "ini" config format
> with embedded JSON where needed (my own monster), and that has worked
> okay for me.  I *want* YAML to meet my needs.  But lack of the
> "writable" goal means it doesn't.
>
> Best regards,
>
> Brad

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140

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