| > 7. Let's keep the special type names as '<type>!' instead of '.<type>'.
| It seems we agree to skip the "<type>!" shorthand. As for specifying the
| exact semantics of "relative types", are you *certain* we want to get into
| it right now? I wouldn't mind one but just to keep the current wording:
| reverse DNS and IANA based names are reserved for their owners, single-word
| names are private, anything else unspecified (yet). At most add wording
| saying that names starting with '.' or '/' are reserved.
I think that brian wanted to keep a short-hand so that
!map meant !org.yaml.map ; he agreed that !!Data:Dumper
could be a private area...
| > 8. We can add a '^<index>' descriptor for sparse lists (I've no strong
| > opinion).
| It seems we all agree '@' would have been best, except for the fact it makes
| it impossible to use @ for indicating lists (if we need it). Again, I think
| using '[' as an indicator is a bad idea (that's too useful a character to
| waste on being an indicator). We also can't use an unannotated number -
| that's rather confusing.
Right. This one is still open. But note: It's a new feature.
| > 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:
| There seems to be a need in Perl to be able to "bless" an empty list or an
| empty list. Hmmm. Would the following do:
| 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.
not-allowed: !money -23.38
| Reasoning: a map-based perl class is defined as an explicit YAML type. This
| type can accept as a valid value a map with a certain set of keys, OR a text
| string (the empty one).
| A list-based perl class is also defined as an explicit YAML type; this type
| can accept as a valid value a list with certain set of entries, OR a text
| string (containing a single '-').
| If you don't like '' and '-', you can replace them with any other
| non-indicator string; for all I care, it can be the strings "empty-map" and
| 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?
| > 13. We can have multiple line breaks indicate a top-level list.
| It seems we now agree on using '----' as seperator instead - however, unlike
| the previous time we had them, multiple instances do not indicate "empty
| chunks", they are simply ignored. Right? I can live with that.
I think that's right. If one wants a blank node, we can
| I disagree that a top-level string is interpreted as a scalar,
| I think it should be a key:
| "this is a
| quoted key" ::
| "not a value"
| "This is a quoted value"
| : "So is this one"
| This is a block value
| This is an unquoted value
| So is this one
| - This is a list entry
| this is : a key
| Note that this clear distinction is only possible because the
| next-line-scalar indicator isn't identical to the list-entry indicator. So
| if the list-entry-indicator goes back to ':', we'll have to return the
| next-scalar indicator to '\'.
This is OK. I'm not too concerned with the details here.
But I did have an idea... and it seems a bit simpler
since we can use the "map" grammer...
"this is a quoted value"
This is an unquoted value
this: is a map
- this is a list
This is a block value
It starts indented one tab.
This is a block value with a chomp
| > 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" this would
be a good mathematical term that usually isn't bothered with
specific implementation assumptions. Array usually assumes
quick access, quick appending, and slow insertion. List
(as in linked) usually implies slower random access,
but fast insertion at any point. YAML does not imply either
of these... thus sequence may be nicer.
| > 20) Reserve '=' for implicit tuple serialization. Reserve !tuple as
| > well.
| I'm against it. I agree with Clark that 'tuple' is just an explicit type,
| and does not require a new list entry indicator. <chomp/>
| 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).
| OK, that leaves one big issue - the relative type names. I'm starting to
| regret I ever mentioned it :-) At any rate, let's see what we want to gain
| from this:
| - The ability to write reasonably short names.
| - Especially for org.yaml.* types (rank has its privilege etc.)
| - Allow private types.
| - Don't mess the information model.
| - Make it readable (as little magic as possible).
| The only know way to do this is to somehow establish the concept of a "type
| conetxt", which is associated with the natural scoping rules of the
| document. In XML this is done via xmlns="...". That would map in YAML to
| something like:
| key: !any-type ^type-context
| sub-key: !<indicator, say '.'>type-in-sub-context
(note: I like ^ for the sub-context indicator)
| Think of '^type-context' as a directive to the parser on how to convert
| "relative types" into "absolute types". Essentially it specifies a prefix to
| be added to the type name before the application even sees it. The emitter
| is free to generate type-context directives to make the output look
| "better"; this is at the same level as deciding to emit a certain scalar as
| a block to make it look better. There's no "type context" in the information
| Another way to do this is to overload the type declaration. This is built on
| the observation that in many cases, the type context is shared between the
| 'key' and the 'sub-key' above. In YAML this may look like:
| key: !some.absolute.type # establishes some.absolute.* context
| sub-key: !.other-type # uses that context.
| Again, this is done at the parser/emitter level, NOT in the information
| Now, note that either way this means that you can't cut-and-paste safely
| without ensuring you get the appropriate "type name context" as well.
| In-memory this isn't much of a problem because we tend to rely on the
| language's built-in type system, but it is an issue when doing text-based
| operations or when handling unknown types. That's a big minus - many a
| battle was fought in SML-DEV over this point.
Right. But such conversations came down to two:
(a) automated systems won't have a problem
(b) human systems can grok the complexity
(c) if a human isn't sure, they can be explicit
| *Assuming* this is acceptable:
| 1. Shoule we use an explict context-setting directive or to overload the
| type declaration we already have. There are pros and cons here both ways.
| For example, using an explicit "type context here" makes it easier to detect
| it when doing cut & paste, and it allows attaching a type context to
| differently-typed node. For example:
| list-of-invoices: !com.company1.type ^com.company2.
| - !.invoice
| This was raised as an issue in SML-DEV. There's little actual experience
| with this sort of applications, however, so it is unknown whether this is a
| concern or not.
| The down side is that any explicit context-setting mechanism requires
| lookahead in the emitter (to intelligenty choose the context). Also, it is
| additional explicit magic (as opposed to additional implicit magic :-)
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.
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.
| 2. Assuming we overload the type declaration, how do we know what part of it
| is the "context"? The easiest way would be to just strip the last word:
| context: !some.absolute.type # context is 'some.absolute.'
| sub: !.another # type is 'some.absolute.another
| another: !..type # type is 'some.type' because '..' is "up"?
| But one may also explicitly annotate it:
| context: !some!.absolute.type # context is 'some.*'
| another: !.type # type is 'some.type'
| This allows to establish a context for an untyped node:
| context: !some.absolute.! # This node is untyped!
| sub !.type # The type is 'some.absolute.type'
I don't like either of these mechanisms to
get at the "grantparent" context. The ! in
the middle, or the ".." gives me a headache.
I would vote for the initial system only handling
the "leaf". In otherwords, the simplest form.
This should catch 90% of the needs. The other
10% (or much less) can just be verbose. That said,
if we found the 10% to be distrubing, we could add
the explicit suggestion in point #1 above without
disturbing our first pass (the simplest version)
| 3. As for a special shorthand for 'org.yaml.*', we can use, say '!' for
| sub: !!.tuple # org.yaml.tuple
| 4. Private types: Simply don't start with '.'.
I'd rather stick with Brian's suggestion.
| 5. When using IANA based types the reasonable syntax would have been '/' for
| indicating a relative type, not '.'. Perhaps the best way would be to be
| agnostic to this (assuming explicit declaration of the context):
| context: !context-prefix!this-node-type(optional)
| relative: !!gets-the-context-prefix
| absolute: !does-not-get-the-prefix
| yaml: !^yaml-type
IMHO, too complicated. Let's not worry about
anything *but* DNS based names.