Re: (spec 3.1.3: presenting ...) how to guide a YAML emitter

On Wed, Apr 16, 2008 at 10:50:51PM +0200, Joachim Wuttke <j.wuttke-97/[email protected]> wrote:
> 
> when processing data through a load - modify - dump cycle, the YAML
> parser eats what it considers "presentation details", and the YAML
> emitter produces output that is much less readable than my original
> hand-formatted input.
> 
>     (To be specific: I have tons of data lines like
>      - [ 0, 3, 2, 5, 9, 9, 9, 0, 0, 1, 12, 1, 3, 3, 2, 0, 0, 14 ]
>      which I occasionally need to inspect by eye.
>      If they are presented like
>      - - 0
>        - 3
>        <and so on>
>      the main advantage of YAML (cf. the order of priorities in spec 1.1)
>      is lost.)
> 
> Spec 3.1.3 explains nicely why this problem is inevitable. It correctly
> concludes that the presentation needs to be "guided by the preferences
> of the user". However, it does not say how this guidance can be imposed
> on a YAML emitter.

I imply that this is referring to "creation" of yaml documents.

What you are doing is slightly different - you are "processing" an
existing (hand crafted) yaml document.

In your specific case, the "preferences of the user" are very clearly
identified by your original (input) file/ 'document'.

However, what you need is a yaml processor (parser + emitter pair),
which go beyond the raw spec and do the (optional) 'user-guidance'
honouring.

AFAICT, such a yaml processor does not yet exist.


> I could think of two ways to guide a YAML emitter:
> 
> (1) On scripting language level: To use Ruby terms, one could introduce
> class and instance variables of YAML, String, Array and Hash in order
> to specify at various levels how an entity should be formatted. Kind
> of
>       a = [ 0, 3, 2, 5 ] # create Array
>       a.yaml_hints.push( YAML.InlineAlways )

Using comments/ scripting would be one way to 'guide' a yaml processor
(or perhaps more specifically, "emitter"). At least, one which is
prepared to do such user guidance honouring.

But, when all the information is already embedded in the layout as per
the original document/file itself, such comments-based-guidance is
entirely redundant, and should probably be frowned upon.


> (2) On the level of YAML specification, allow a simple way to preformat
> data structures within YAML dumps. Say, I want to dump a complex entity
> ydat that somewhere contains my precious array,
>       ydat["Data"]["essential"][197] = [ 0, 3, 2, 5 ].
> As I do not like the default format of the emitter, I replace the array
> by a string,
>       ydat["Data"]["essential"][197] = "[ 0, 3, 2, 5 ]".
> Dumping ydat, I obtain
>...

I don't agree that this is something that should be handled at the
specification level. Parsers/ emitters must be able to be (relatively)
simple and yet conforming.

All you're after is a specific yaml processor with a few extra bells and
whistles.

Zen

-- 
Homepage: www.SoulSound.net -- Free Australia: www.UPMART.org
Please respect the confidentiality of this email as sensibly warranted.

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone