YAML Ain't Markup Language

What is standing between us and a spec at this point:

- Scalar forms. I summerized the new proposal, which requires 5 separate
scalar types. We can go with it, keep things as they are today, or try to
simplify it further.

- References. OK, Alias != Pointer. Fine. Now, how does YAML serialize
"\$a->[0]"? I posted an example showing why this is hard (and how
Data::Dumper gets it wrong). I also showed how it can be done given some
creative use of the '!ref' type. We need to decide on this.

- Info model. If Clark comes up with a reformulation of the info model that
JAP can grok, I'd be happy to include it into the spec, and more than happy
to re-work the simpler productions :-)

- Pipelining. Let's leave it out for now - right?

- YPATH, APIs. Let's not go there yet.

Did I miss anything?

At any rate, we are very close. Let's finish it.

I have two days of military reserve duty tomorrow and the next day (don't
worry, just holding the hand of some youngsters who want to muck around in
my infrastructure code, dated '88 or so :-). So I'll have a spotty
connection for two days - just my evenings, I guess. I'll try to think the
scalar format over in the mean while...

Have fun,

    Oren Ben-Kiki

On Mon, Nov 12, 2001 at 10:49:47PM +0200, Oren Ben-Kiki wrote:
| - Scalar forms. I summerized the new proposal, which requires 5 separate
| scalar types. We can go with it, keep things as they are today, or try to
| simplify it further.

How about...

block: |
 This is a block scalar (no implicit or escaping),
 it is very simple no suprises.  WYSIWYG
folded: \
 This is a folded scalar (no implicit or escaping)
 it is very simple, no suprises (other than the
 line folding propery).
other:
 - We throw everything else into the third form.
 - It can be single line as above, or it
  can wrap on to the second line like this one.
 - "it can be single ' or double \" quoted.\n
  Also, this form can be implicit, as the next
  the next one shows..."
 - 345

In this way, "other" is almost identical to the
"key" syntax, only that multiple-line unquoted
scalar is not allowed.   Further, the "key"
syntax is probably what will be used in YPATH.

| - References. OK, Alias != Pointer. Fine. Now, how does YAML serialize
| "\$a->[0]"? I posted an example showing why this is hard (and how
| Data::Dumper gets it wrong). I also showed how it can be done given some
| creative use of the '!ref' type. We need to decide on this.

Since it appears Perl is kinda "broken" here... Brian?
The Perl version could just treat it as one
would expect from seralizing C, where access
to a member of an array doesn't imply knowedge
of the array.  This way Pointers are dumb, and
can probably transfer to other langauges that 
have pointer mechanism.  

That said, if the construct described would be 
serialized in the dumb way... is it consistent?
If so, then i'd say do a dumb serialization
(without the array knowleege) and issue a warning
if such monsters are encountered.  This one is
squarely in Brian's domain.

| - Info model. If Clark comes up with a reformulation of 
|   the info model that JAP can grok, I'd be happy to include 
|   it into the spec, and more than happy to re-work the simpler
|   productions :-)

Great. 

| - Pipelining. Let's leave it out for now - right?

Base64 is the only use case... it'd be nice to have
a cleaner solution for this though.  Perhaps it's best
just to include base64 methods and let the user handle
the issue...
 
| - YPATH, APIs. Let's not go there yet.

Ok.  However I don't think we can move to "release canidate"
till some of the APIs are worked out, in case there is
some inconsistency we need to fix-up.

| At any rate, we are very close. Let's finish it.

+1

Clark

On 12/11/01 22:49 +0200, Oren Ben-Kiki wrote:
> What is standing between us and a spec at this point:
> 
> - Scalar forms. I summerized the new proposal, which requires 5 separate
> scalar types. We can go with it, keep things as they are today, or try to
> simplify it further.

I like the syntax & semantics of these 5 types *exactly* as you posted. 

> 
> - References. OK, Alias != Pointer. Fine. Now, how does YAML serialize
> "\$a->[0]"? I posted an example showing why this is hard (and how
> Data::Dumper gets it wrong). I also showed how it can be done given some
> creative use of the '!ref' type. We need to decide on this.

I'll handle Perl with what we have. Enough said.

> - Info model. If Clark comes up with a reformulation of the info model that
> JAP can grok, I'd be happy to include it into the spec, and more than happy
> to re-work the simpler productions :-)

OK

> - Pipelining. Let's leave it out for now - right?

I just want to know how to serialize:

print YAML->Emit(bless [], "Foo::Bar");

--- !seq !!Foo::Bar
# This is an empty seq

--- !seq!!Foo::Bar
# This is an empty seq

--- !!Foo::Bar!seq
# This is an empty seq

--- !!Foo::Bar=seq
# This is an empty seq

I can always get away with the last one as a trick, since '=' would never be
in a Perl class name.

> - YPATH, APIs. Let's not go there yet.

I couldn't if I wanted to.

> Did I miss anything?
> 
> At any rate, we are very close. Let's finish it.

Yaml Baby, Yeah!

Hey, final note. What's going to keep us from mucking around with it when
it's finished? I think we should all agree on some kind of frozen period,
where nobody is allow to suggest major changes until we get a few
implementations completed and though an alpha test phase.

Cheers, Brian

On Mon, Nov 12, 2001 at 09:45:48PM -0800, Brian Ingerson wrote:
| > - Scalar forms. I summerized the new proposal, which requires 5 separate
| > scalar types. We can go with it, keep things as they are today, or try to
| > simplify it further.
| 
| I like the syntax & semantics of these 5 types *exactly* as you
| posted. 

Agreed.

| > - References. OK, Alias != Pointer. Fine. Now, how does YAML serialize
| > "\$a->[0]"? I posted an example showing why this is hard (and how
| > Data::Dumper gets it wrong). I also showed how it can be done given some
| > creative use of the '!ref' type. We need to decide on this.
| 
| I'll handle Perl with what we have. Enough said.

Ok. 

| > - Info model. If Clark comes up with a reformulation of the info model that
| > JAP can grok, I'd be happy to include it into the spec, and more than happy
| > to re-work the simpler productions :-)
| 
| OK

It'll take me a few days.. I have day job work to do.

| > - Pipelining. Let's leave it out for now - right?
| 
| I just want to know how to serialize:
| 
| print YAML->Emit(bless [], "Foo::Bar");
| 
| --- !seq !!Foo::Bar
| # This is an empty seq
| 
| --- !seq!!Foo::Bar
| # This is an empty seq
| 
| --- !!Foo::Bar!seq
| # This is an empty seq
| 
| --- !!Foo::Bar=seq
| # This is an empty seq

By golly.  Our second use case.  That's two, adding
an empty map, that makes three.  Sounds like we need
a bit of thought on this one.  Assume we modified the 
information model so that each class had a stack of 
classes?  Thus, the examples would be...

--- !gif!base64 \
 R0lGODlhGQAPAOMAAAICBDaanAJSVAISFP7+/G
 bOzAJmZAIeHGbMzGbMzGbMzGbMzGbMzGbMzGbM
 zGbMzCH+Dk1hZGUgd2l0aCBHSU1QACH5BAEKAA
 YALAAAAAAZAA8AQAR70EgZArlBWHw7Nts1gB6R
 GV0wCBMlkp4qlHJppkNoyW1r5SmcTeV6wUwrFI
 4VEulSMyRLchhYrYLq4MDKYrm9XuFQuIzLhALA 
 pm6VV+g44FBSHybokQGdnivNfhJ8enwFSR12eB
 4jcWZ3gHeCJQJycXSJEzaIc5SIWz0RADs=
--- !!Foo::Bar!seq 
 #an empty foo sequence
--- !!Foo::Bar!map
 #an empty foo mapping


| > - YPATH, APIs. Let's not go there yet.
| 
| I couldn't if I wanted to.

As long as we don't "tighten down" the information
model before we have an first pass implementation.


| > Did I miss anything?
| > 
| > At any rate, we are very close. Let's finish it.
| 
| Yaml Baby, Yeah!
| 
| Hey, final note. What's going to keep us from mucking around with it when
| it's finished? I think we should all agree on some kind of frozen period,
| where nobody is allow to suggest major changes until we get a few
| implementations completed and though an alpha test phase.

Sounds good.

Best,

Clark