Practical Considerations for a Future YAML

Hi--

Having used YAML for a number of years now, I've been able to
formulate some general heuristics surrounding my application of the
format in practice (in contrast to the theory). My use cases have
mostly centered around the human readability of the format rather than
it serialization capabilities, but I have considered that use in light
of my thoughts as well. This is what I have noticed.

1) I rarely use type declarations. Usually because I can anticipate
types in my application without them. But even when types are needed,
I shy away from it in favor of a mapping key b/c the present syntax of
the type declaration (i.e. !) is distracting to the eye. In other
words, instead of:

  something: !mytype
    foo: bar

I do:

  something:
    type: mytype
    foo: bar

More often the not I'm dealing with a mapping so the above is fairly
clean, but even if I am not working with a mapping, I'm inclined to
add an extra layer:

  something:
    type: mytype
    body:
      baz ...

Again, human readability (and edit-ability) is my main focus here and
leads me to think that the type declaration syntax could be made more
human friendly.

2) I never bother with !! vs. !. Of course, as I said above, I don't
use either much, but when I do I have never worried about the
distinction between them, regardless of the long argued flip between
v1.0 and v1.1. The reason is simple, my application decides how to
treat the types. If my app wants to treat !str as something other
then !!str, then it does so, otherwise it just "passes it off" as the
same as !!str. In other words, I work with the documents with the
frame of mind that every type is a private type that "inherits" from
the public one if it exists, and which I can override if I need to
(though I have never needed to do so).

3) More often then not, I want literal strings, not folded ones.
Unfortunately the bar syntax '|' is an eye sore and something easily
forgotten. It would be much better for strings to default to literals
since an application can always fold the text itself if it needs to do
so. Though other indicators (eg. >) are fine to have as options too.
When serializing, I suspect the same holds true. This issue is so
problematic, that it leads me to actaully pre-parse YAML streams
manually, so that I can get literal strings without the | symbol.

4) I have never put actual content on the same line as the document
marker (---).

So how might these practical points translate into a future version of
YAML?

* No syntax distinction made between private and public types.
* Document markers (---) never have content. And can designated type
without a marker.
* Reuse '---' within the document, creating a nice YAML in YAML
situation.
* For in-line content, designate types with a dot or maybe a pair
brackets, which look better.
* Default strings would be literal, and '|' (or some other character)
would be used to mean folded.

So an example, per above, might look like this. Using "YAML in YAML":

    something: ---mytype
      foo: bar

Not using "YAML in YAML":

    something: .mytype
      foo: bar

or

    something: (mytype)
      foo: bar

Of course, I'm sure there might be issues with these syntax
constructions, but I am hopeful they can be worked out satisfactorily.

Lastly, I'd be interested in hearing other's considerations from using
the format in practice.

Thanks,
Trans

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july