RE: [Yaml-core] My Court

[Oren Ben-K. <or...@ri...>]

Clark C . Evans wrote:
> | > 8. We can add a '^<index>' descriptor for sparse lists (I've no
> | > strong opinion). 
> ...
> Right.  This one is still open.  But note: It's a new feature.

Yes.

> | > 10. There's no need for a magical empty map/list descriptor
> | > beyond the 
> | > explicit map/list type name. 
> | 
> | This is still open. My proposal:
> | ...
> | blessed-empty-list: !perl-class-name -
> | blessed-empty-map: !perl-class-name
>
> I don't think this will work, beacuse it will make - an 
> indicator in this context.

No, it is just a particulat scalar value. Not an indicator. This *would* be
allowed:

>  not-allowed: !money -23.38

> | The point is that there's no need to have these strings be indicators.
> | It is
> | just an explicitly typed scalar, which is deserialized into the
> | appropriate
> | native data structure - a blessed map or list as the case may be.
>
> Your point is... that the class will know what it's storage
> requirement is.  This works as long as the class is supported
> by the given operational environment, right?

Not at all. A Perl parser seeing an unknown type can look at the scalar, if
its empty bless an empty map, if its '-' bless an empty list, and otherwise
do whatever it does with unknown-type scalars. Which does not make '-' an
indicator. It doesn't even make '' and '-' members of an implicit type,
since the node is explicitly typed here.

What *wouldn't* work is a non-map explicit type which has "" as a valid
value, or a non-list explicit type which has "-" as a valid value. In a Perl
system *which doesn't know the type*, they will be interpreted as
blessed-empty-map and blessed-empty-list. I don't think this is a real
problem.

> | > 13. We can have multiple line breaks indicate a top-level list. 
>
> But I did have an idea...  and it seems a bit simpler 
> since we can use the "map" grammer...  

Interesting, but see my other post with a new idea about these and comments.
I think being able to "grow into" MIME is an important feature.

> | > 19. Let's consider changing the term 'list' to 'array' in all YAML 
> | >     documentation. 
> | 
> | Open issue. Is that's due to the array/tuple distinction?
>
> Hmm.  Let's compromise and call it a "sequence"...

Fine with me.

> | > 20) Reserve '=' for implicit tuple serialization. Reserve !tuple as
> | > well. 
> | 
> | I'm against it...
> | tuple: !org.yaml.tuple
> |     - First slot
> |     - Second slot
> | 
> | Like "ref" for Perl, "tuple" is a prime candidate for a shorthand name
> | (whatever mechanism we come up with eventually).
> 
> Yep.

OK then.

> | OK, that leaves one big issue - the relative type names.
> | I'm starting to regret I ever mentioned it :-)
> | ... this is done at the parser/emitter level, NOT in the
> | information model.
>
> Right.

Good.

> I think an implicit mechanism is probably the best
> in this case.  From Don Park's experience, he often
> quotes that most data comes in islands.

And the container of the island had a name with the right prefix? At any
rate, I can live with it, I'm just pointing out it is a mine field and that
we don't want to fully settle it.

> Also, we could just use the implicit model, and 
> if it doesn't work add the explicit one (which
> would override the implicit mechanism) later,
> if we found it was absolutely needed. In this
> way we don't overly complicate the system up-front.

Sounds reasonable. So what's the current state, I'm losing track here:

absolute: !dns.based.absolute
    relative: !.type # == dns.absolute.type
    private: !has-no-dot
    yaml: !!map

Or is it:

    private: !!has-explamantion
    yaml: !has-no-dot

I prefer the former, I think. '!!' seems more "important" somehow, I don't
want to glorify private types :-)

> Let's not worry about anything *but* DNS based names. 

Does that mean we should take out the wording about reserving type names
starting with a IANA type names? Being able to write:

arrow: !image/gif [=base64=]

Is rather neat, I'd like to keep that.

Have fun,

    Oren Ben-Kiki