Clark C . Evans [mailto:cce@...] wrote:
> | I think I missed the point of the latest ideas.
> I believe Brian's need for a new top level separator
> construct is that he has two different "types" of
> sequences: lists and arrays...
> From Brian's examples, the "list" type seems to be
> introduced during function calls and returns
It seems to me rather strange to have YAML directly support *in syntax* a
type only used implicitly in function calls in one language. Sorry.
I *do* like separators now, but for a different reason. If they also happen
to solve Brian's problem, fine.
> | Python tuples vs. lists can be neatly covered by an
> | explicit type (as would Perl arrays vs. lists if there
> | is such a thing). If you feel that we should
> | define two additional core/common types, 'list'
> | and 'tuple', in addition to 'seq', so be it - as long
> | as you can come up with a good language-independent
> | definition of seq, list and tuple which would make
> | sense to, say, a Java or a C++ programmer :-)
So I'll stay tuned for such a definition, and in the meanwhile we'll stick
> | About attaching descriptors to the top-level. That's
> | covered in today's spec:
> | !typed
> | - top-level list
> ok. One question. If I have two of these buggers
> and then I concatinate them I get...
> - top level list
> - top level list
> Is this valid?
> This is the reason why I chose the
> comment syntax.
I don't see how it can be valid there either. Is "#!type2" a separator here:
> | !typed
> | top-level : map
> I'm confused with this one. Is the top-level
> key typed, or is the map?
> Another good reason
> why the comment syntax works.
Or the separator one:
!key-type key : ...
> | !typed \
> | top-level scalar
> This is a good example of why I don't like top-level
> scalars. One could just as easily add a "-" in front,
Or, for that matter, a '---' :-) Also note that using a '---' you wouldn't
need to indent the scalar!
--- !typed \
Non-indented - I love YAML!
> and then we don't have to have special production
> rules... this works especially well if the type of
> the top level list is a "transfer vector".
If it is a list... I don't see the YAML spec has to get into the issues of
the exact return type of a Perl call to de-serialize a YAML document. As
long as reasonable syntax is *possible* - that is, we aren't *preventing*
the use of transfer-lists or whatever - that's OK.
> | !typed top-level map key : with value
> Kinda subtle hunh?
Yes, so I'm *not* proposing that. I propose that the '---' would be
*required* if there's any form of descriptor or indicator added to the
> | No need for magical comments.
> if you don't like the magical comments, that's
> ok. But how do we do concatination of docs
> in this case?
!key-type key : value
- list entry
key" : value
Back references are not allowed to go across '---' for safe splitting.
I think this is clean, readable, solves Brian's problem, the concatenation
problem, the splitting problem, and even the version problem:
> Ok. Then let's burn a "special" indicator to
> mark version and give discriptos to top level
> constructs. Let's use, for example the ?
> ?YAML v1.0 !vector
Do it like this:
--- YAML-1.0 !vector
--- YAML-9.5 ...
Note that you have all the freedom in the world to define what comes after
the '---'. You don't need the '?' (of course you can have it if you want).
In fact I consider this zone after the '---' and before the first indicator
character to be a great advantages of this proposal. It allows us to add
anything we want there, not just version information (e.g., think of
specifying a schema link, or whatever).
> The advantage of this is that we don't need
> another sequential construct. We add a single
> "roadsign" (later road signs must be identical
> or it is an error), remove top level scalars,
> and we are done.
I much rather have this roadsign be called '---', add to it the semantics
that it blocks back-references, and allow it to contain a top-level scalar
value. Other than these "minor" changes, I completely agree :-)