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

[Clark C . E. <cc...@cl...>]

Oren,

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.
Thus, we should have !binary instead of !base64

| > You can mandate that only the built-in transfer methods
| > are supported and that all other types are treated as
| > strings.  This seems resonable and consistent.
| 
| I guess so, though I see no harm in allowing YPATH to
| "grok" additional types.

Yes.  A transfer method "driver" mechanism could
work, where in the YAML layer, operators for each
transfer method could be provided.

|                 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.
So, I'd rather think of it this way.

                            abstract model
                            .           .
                            .           .
                            v           v 
  serialization  ->  serial model  -> native model
             (parser)            (loader)


In this way, you could say that a transfer method
(in the serialization model) represents the 
type family in the abstract model.   Thus, the
distinction between the transfer method and 
type family are clearly made...  

| > 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.  ;)

Clark