From: Clark C . E. <cc...@cl...> - 2001-11-06 14:33:07
|
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 |