On Thu, Oct 25, 2001 at 06:01:33PM -0700, Brian Ingerson wrote:
| > 2. We can use ':' instead of '\' as the next-line scalar indicator (though
| > I'd rather keep '\').
1. So :: is a next-line scalar.
2. Quoting can be with either " or '
3. nextline unquoted can't start with a quote.
4. Using |- for chomp.
| > 4. We can add in-line block values (I've no strong opinion).
| NO! I mean, "I'd rather not".
| > 5. Let's use '-' instead of ':' for list entries (unless someone feels
| > strongly against it).
Ok. Let's tentatively set it as a dash then, we can change
it back to a colon if we find it problematic.
| > 7. Let's keep the special type names as '<type>!' instead of '.<type>'.
| Defer to you guys.
You cover this in your #22, let's defer till there.
| > 8. We can add a '^<index>' descriptor for sparse lists
| (I've no strong opinion).
| I like '@'.
| is it
| -@... twelve
| - @12 twelve
| or both?
I like the first, but the second is more consistent
with using whitespace as the delimiter...
| > 9. We can restrict unquoted keys to one line (I've no strong opinion).
| > 10. There's no need for a magical empty map/list descriptor beyond the
| > explicit map/list type name.
| OK :(
Let's keep this as an "open issue" for now, but
still move forward. The problem is representing
a empty blessed map in perl. You can have one
or the other, but not both. This may cause us
to bring back the (%) map indicator *sigh*
| > 11. Let's have an *optional* central registry for implicit types.
| Defer. As long as we have implicit types, I'm cool.
Good deal. Oren and I will dream up some language
| > 12. There's no need to be able to serialize the ! and & keys.
| OK. But we still use the internal trick to round trip data. Right?
IMHO, each language binding will have to worry
about round-tripping explicit types that it doesn't
handle natively. How it does this is probably best
done in the context of the language itself... given
that the serialization language won't be impacted.
An example, would be promoting a scalar to a map
with special keys. In any case, the implemetation
should offer a warning when ever this sort of
| > 13. We can have multiple line breaks indicate a top-level list (though I'd
| > rather use a list syntax).
I agree with Brian's use of three dashes (---) for
a separator. His examples make sense.
| > 14. Let's reconsider using tabs for indentation.
| > 15. Let's not have a special in-line key/value pair syntax for '#'.
| > 16. Let's consider having throw-away comments and other filters as
| > "transfer encoding".
| I like the standard library approach:
| $YAML::StripComments = 1;
| my @series = YAML->thaw('file.yaml');
| But, whatever you guys feel is appropriate is fine. That said, I'll most
| likely put a comment stripping option in my Perl implementation.
Ok. As long as the API does not strip comments
by default; i.e. it requires developer interaction
to change the default.
| > 17. Let's not have a next-line form for the quoted
| > scalar, so that the multi-line scalar is simpler.
| I agree with the latest logic on this (which is "disagree" :). But I
| also want to allow single quotes to work the same as double quotes, so
| that a string can start with either.
Ok. I can live with this decision, and it seems consistent.
However, note that you can't have a un-quoted, non-block
scalar that begins with a single or double quote.
| > 18. Let's allow for multi-line scalars to begin on
| > the first line and extend to further lines, eg.
| Yes. Of course. But not for blocks, of course.
| 19. Let's consider changing the term 'list' to 'array' in all YAML
| 20. Reserve '=' for implicit tuple. Reserve !tuple as well.
I don't think reserving '=' is required, but I will
live with it. The following is just fine and works
well for python people.
| tuple: !tuple
| - foo
| - bar
| 20a. I assume we are completely rid of:
| foo: !class
| =: value
| Since that is easily represented as:
| foo: !class :
| 21) I think the type indicator should immediately follow
| the colon or dash,
| regular string::
| regular string::
| "Hello YAML"
| anchored string:: &005
| "Howdy YAML"
| classed block:|- !my.text
| 22) Let's use the following classnames:
| - !com.FatPort.foo "Explicit - fully qualified"
| - !2.bar.baz "Relative - 'com.FatPort.bar.baz'"
| - !.My.Class "Private - unregistered"
| - !date "Reserved - for YAML types"
Let's work through this one. I snipped your
rationale. A few items:
1. The "relative" .Class mechanism works very
well if you look up the ancestor tree for
the first DNS based class that is not-relative.
Pop the right most class, and then append the
core class. Example:
is equivalent to..
One would rarely want to go up more than
one level. And if so, the full explicit
class mechanism is available.
2. For a yaml type "type", we could just use
fully qualified YAML names: org.yaml.type
And... for a common short-hand we can specify
that there is an implicit "fixed" base
of "org.yaml." so that the relative ".type"
means "org.yaml.type" unless there is an
absolute DNS based class in it's ancestor
spec: !org.yaml.BigInt 345
Is equivalent to...
date: !org.yaml.date 2001-11-01
spec: !org.yaml.BigInt 345
This is a simple mechanism where the fully
qualified YAML is rather rare.
3. The last class "private" is any class without a period.
Thus: !Data::Dumper ~
bla bla bla
We can use !type for all yaml types and then use
a double exclamation !! for private types.
| 23) Class names are case-sensitive. Any part of the name that is a
| real domainname *should* always be specified in lower case.