RE: [Yaml-core] Model, Transfer Etc.

[Oren Ben-K. <or...@ri...>]

Clark C . Evans [mailto:cc...@cl...] wrote:
> I've got a small difficulty with !base64 and
> the binary type family.   With integer type 
> family, there is one transfer method, !int
> which has multiple format/encodings: 
> hex, octal, and decimal.  Why shouldn't
> the binary type family be !binary with
> support for multiple formats, one of them
> being base64.   In other words, I don't see
> why base64 should be a transfer method; it
> seems that it's better described as a format.

Because if you consider, for example, zipped binary (which would also happen
to be base64 encoded), there's no way the transfer method would be able to
auto-detect which format to use. In integers we have taken care to provide
explicit base markers. You could, I suppose, say that one has to write:

data: !binary BASE64...data...
more: !binary ZIP...data...

But that's ugly as sin. Using !base64 and !zip seems much cleaner.

> |                 serial model  abstract model
> |                        |               |
> |                        V               V
> | serialization -> private API -> native model
> |            (parser)       (loader)
> 
> Well, I don't think the API will be that private,
> as libyaml will export it; libyaml will provide
> the parser/emitter pair but not the loader/dumper.

You made a good point that in C/C++ there aren't good native structures one
could map to and you'd have to roll your own. This is s powerful motivation
for defining a good interface between the parser and the loader so that
different structures could be used by different applications. I agree.

Change 'private API' to 'API' in the above. Done :-)

> So, I'd rather think of it this way.
> 
>                             abstract model
>                             .           .
>                             .           .
>                             v           v 
>   serialization  ->  serial model  -> native model
>              (parser)            (loader)
> 

Nope. The serial model defined in the spec is not an API, it does not
specify which data structures/calls you use. It is a set of constraints on
the actual implementation you'll be writing in libyaml. Think of it this
way:

                serial model  abstract model
                       |               |
                       V               V
serialization -> libyaml API -> MyAppDataType

Saying the serial model is at the same level of abstraction as the native
model is confusing. One is a set of words on paper and the other is working
code.

You could argue that the serial model is a "derived model" of the abstract
model. So add a "<<" between them:

              serial model << abstract model
                       |               |
                       V               V
serialization -> some API -> native model
           (parser)       (loader)

That should cover it. Someone should write this in UML :-)

> | > The style does not affect the transfer method, no?
> | > This has got to make it into the spec!
> | 
> | Right, but note that a transfer method _is_ aware of at
> | least the *kind* of node it is working with.
> 
> Not the style though.  ;)

Right.

Have fun,

	Oren Ben-Kiki