[Yaml-core] (backfill) YAML Meeting Minutes: 17-MAY-2001

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

----- Forwarded message from "Clark C . Evans" <cc...@cl...> -----
Date: Fri, 18 May 2001 09:48:50 -0500
From: "Clark C . Evans" <cc...@cl...>
Subject: Re: Meeting Minutes

On Fri, May 18, 2001 at 12:41:20AM -0700, Brian Ingerson wrote:
| I don't think it's that important to investigate. It will probably
| always be a moot point. I will let Data::Denter use it's current scheme
| to deterministically round-trip all Perl data structures. YAML.pm
| probably will have no need for this. It's all acadenic and I have no
| spare time for academics for three more months. (My guess is, yes it
| could be made to work, but would be suboptimal for Perl people) Let's
| leave it at that for now.

Ok.  I'm curious about what syntax you will deploy.

| On 4 & 5. I don't really like the blank line at the beginning thing
| because people will mess it up or not understand it. And we have many
| heuristic options.
| 
| A) Parse lookahead for X-YAML-Version
| B) Option-A rarely needed because as soon as we see a key that is *not*
| RFC822 compliant, we assume YAML. 99% of the time this is the first
| line!
| C) If there is no whitespace allowed before the colon in RFC822, we
| simply make it a requirement in YAML. Or does this break your RFC
| compatability rules?

A&B are good.  I don't really care about C, perhaps in the 
interest of consistency with both RFC822, but also Python
code, we may not want to require the space before the colon.

| Just for my own edification, would you please explain the rationale
| behind making YAML RFC822 compliant. And do so with one of more specific
| examples. Thanks :)

I'm not all that concerned about RFC822 compliance.

I'm more concerned about consistency since we are going 
to allow RFC822 headers.  In particular, if someone
sees a few RFC822 lines above and the YAML lines below
the seperating blank line, they will most likely assume
that YAML has the same (or very similar rules).  Thus,
those items _common_ in RFC822 should be allowed in YAML.

There will be a laundry list of RFC822 constructs that
when moved into the YAML section will be illegal.

| Neil and I agree that the normal transport mechanism between Perl and
| Python serializer/parsers would definitely *not* be a mailer. And if a
| mailer was used, most people wouldn't give a darn about the trailing
| whitespace. And if they really did, we could just encode the whole
| document anyway. So I now definitely think the best-fit answer is:
| 
|     " this is the hash\n key for this example  :-) " : #class :
|        |# My Perl Subroutine
|        |
|        |  sub version {
|        |      if ($_[0] =~ /\n/) {
|        |          return \ "\to sender";
|        |      }        
|        |  }

Nice.  Is this fairly "optimal" for your purposes?

| Sorry for overloading this example with so many weird things.

Not at all.  This is good.

| I'll just comment on the multiline semantics:
| 
| A) Trailing whitespace is preserved if the transporter preserves it.
| B) The content can always be encoded before transport anyway.
| C) Nothing is escaped. The content is truly verbatim. A '\' is a '\'.
| D) An implicit newline is assumed to be at the end of every line.
| E) Note that the '|' is one column back from the actual indentation
| level. This is intententional. And it will work even if the indent width
| is set to one character wide. (not mandatory, but I like it.)
| F) I'd like to push for this always starting on the next line if it is a
| map value. It has no relation to RFC822.
| 
| This will work the way I intended it 98% of the time.

One question.  How are trailing new lines handled?  You may
want to modify "D" so that there is a new line on every | 
line, except the last one.  Thus to get a trailing new-line,
you'd have to do:

  after : 
   | this has a
   | trailing new line
   |
  before : 
   |
   | This has a leading new 
   | line, but not a trailing
   | new line.
  both:
   |
   | This has both a leading
   | and a trailing new line
   |
  another :
   | this does not have
   | a trailing new line,
   | nor a leading new line.

Clear?  I think it beats :- as far as readability.

| > 9. Clark agreed to make a "boostrap" C program
| >    and upload to source forge.  Brian and Neil
| >    agreed to download and hack at will.
| 
| As I walked to the train station with Neil, he figured out the C
| implementation in his head and said he would try to get it done 
| before bed.

Great.  I'll focus on the specification today then
rather than laying-in-code.

| > 16. We made little progress on the scalar indicator
| >     for lists, to colon or not to colon.  It wasn't
| >     agreed, but Clark thinks this is someone else's
| >     monkey.  If Oren and Brian can't agree within
| >     7 days, Clark will put on the dictator cap.
| 
| We traded in the '$' for the ':'. '$' as the last character in a line
| meant a multiline scalar was to follow. Converting this semantic to the
| ':' leaves us with these represntations:
| 
|     key1 : @
|         single line
|         :
|             classless folded
|             multi line
|         another single line
|         and another
|         #class &0001 :
|             classed multi
|             line
|         #class &0002 classed single line
|         %
|             key : value
|         @
|         ~
|         #classy %
|             key : value
|         : even this multi line on the same line
|           as a colon thingy works because there 
|           a little bit of indentation imposed by
|           colon. (Although I don't love it)
|         : "Another thingy like above that meets"
|           "RFC822 wackiness"
|         :
|            |    1
|            |   1 1
|            |  1 1 1
|            |Just for completeness :-)

Good deal.  Your example above, you have two colons:

    " this is the hash\n key for this example  :-) " : #class :

Is the second colon a typo, or is it required per this 
proposal?

Best,

Clark

----- End forwarded message -----