Re: [Yaml-core] New Draft

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

Oren,

Thanks for working through this with me.  I like
the pipeline proposal, and agree we can put it
off to YAML 1.1  if we find use cases which
support the added complexity.

Clark

...

| > | >    picture: !gif [base64 encoded image]
| > |
| > | These are perfectly valid today.
| > 
| > Really?  This only works if the !gif class
| > was some-how associated to use the [base64
| > decoder mechanism.  Let's focus on this
| > use case -- how do we represent a base64 
| > encoded object with an explicit class?
| 
| It isn't the gif class, it is the gif de-serializer. 
| Which is welcome to invoke the base64 routines internally.
|
| !<thing> doesn't specify the *value class*, it specifies
| the *de-serializer* class; of course there's usually
| a 1-1 mapping between these two... Adding a
| paragraph somewhere which clarifies this distinction - 
| the gif base64 image is a good example case.

My proposal was trying to separate this distinction
and make ^ for the "seralizer" class and ! for the
value class.  Perhaps this distinction isn't good
at all... since a seralizer will create an object
of a given value class.

| !gif!base64 (base64 is a de-serializer taking Unicode
| text and giving byte array; gif is a de-serializer taking
| byte array giving gif image). 
| 
| !gif ^base64 (gif is a de-serializer taking Unicode text 
| giving gif image; base64 is a possible format this 
| de-serializer can handle).
| 
| The difference is subtle for the above case; the 
| !<type1>!<type2> proposal allows for arbitrary multi-stage 
| processing (e.g., !ocr!gif!base64, as a really wasteful 
| way to transfer text), while the '^<format>' is restricted
| for only two levels. So *if* we decide this is important, 
| I'd rather go for the pipeline proposal.

Right.

| !gif! (implicitly typed value, resulting type must be
| acceptable to the gif de-serializer - e.g., an implicit
| base64 value will result in the same behavior as above)

Nice.

| That gives you everything you need. However, I don't think
| we should add it in YAML 1.0 (no proven need for this). Instead 
| let's just allow for it in the future. The current wording 
| reserves all names not starting with a DNS entry; let's make 
| it stronger and reserve everything not looking like a DNS
| entry "Regexp: ( (alnum or '-')+ '.' )+ ( alnunm or '-' )+". 
| This means all names containing '!' or other magical characters
| would be reserved.

Ok.  The private area !!private should exclude "private" 
from containing a ! as well, to allow for chaining.

| This way we could add pipelined types later on if they are
| useful. Or any other scheme we feel is necessary. Note this 
| would be backward compatible. A YAML 1.0 application would 
| just have to be given the enumeration of all possible 
| combinations instead of creating a pipeline on the fly like
| a YAML 1.1 application would.

Sold.

Clark