On Mon, Mar 27, 2006 at 02:58:12PM -0500, TRANS wrote:
| Not another case. I just mean that any indication of style should be
| on the first line. So the following two example come out the same:
|
| this: |
| a
| b
| c
|
| and
|
| this:
| | a
| b
| c
|
| but I suggest they not be b/c the style indicator is after a line
| break. The later example should be interpreted as a plan style
| instead. This would help simply styles parsing.
Ahh. Much better explanation, thank you. Actually, older versions of
YAML (say 3 years past?) use to work the way you're suggesting; however,
it really made data-dumps ugly - and this was a rather important use
case. The issue happens when you're neste, say 5-6 deep (or more)
and you've got very long tag names, etc. The result is just unreadable
unless you can move the tag onto its own line. A poor example:
this-particular-node:
- is indented
- quite deeply as you can see:
!str a-very-long-key: &0003 !types.example.org,2006:bingles-and-stuff |2-
This is block content
I suppose we could allow tags to start on the next line, but we erred
on the side of letting anything start on the next line... rather than
only permitting certain indicators.
Another (perhaps not so compelling) use-case for allowing the content to
start on a different line was the use of comments between the key and
the value:
given-name:
# please fill in your first name here
"Clark C. Evans"
In any case, I'm more or less neutral on this one; but a change like
this could cause some pretty serious backwards compatibility issues.
On Mon, Mar 27, 2006 at 02:57:36PM -0500, TRANS wrote:
| First one simple and concrete...
...
| > | mymap: {
| > | one: 1
| > | two: 2
| > | }
...
|
| This is actually a very simple modification. All it means is that a
| line break can also be used instead of a ','. Right now the above
| causes Syck to raise a syntax error, so as it stands it's just unused
| syntax possibility. The simplicity in this case is mainly with regard
| to human readability, although it also adds a very quick way to make a
| document indent independent.
I'm puzzled as to what this would accomplish; most of the time you're
either working with "block" or "flow" styles. I've not yet encountered
a case where I want to convert from block to flow that quickly. I
rarely use the flow style, but when I do its exactly at the places where
I don't want to be constrained to one-node-per-line. I think a bit more
detail would help; in your programming language syntax, how would this
change help?
While it seems a simple modification, I'm not sure what this would do to
the productions. In the next version of the specification I'd like to
see more differentiation between "flow" and "block" plain scalars, in
part to unrestrict the block styles a bit more (since you can count on
indentation to end scope) and add a few more restrictions to the "flow"
style to make it more like JSON, primarly for compatibility.
On Mon, Mar 27, 2006 at 02:59:36PM -0500, TRANS wrote:
| With regard to interpolation, I think YIP is a good starting
| point for a discussion. Below is a small example of YIP.
I like the idea of interpolation. If it was YPath Based, it could
be done with a custom tag, e.g.:
---
author: Bruce Williams
message: !!sub %author% wrote this.
In which case, the '!!sub' tag would cause interpolation to happen
based on the YPath expression. This wouldn't require a change to
YAML, just adding a new standard tag.
| I was thinking the references should use anchors rather than
| YPath but perhaps both are good.
References would probably be better, since you can be sure that the node
won't move on you (and if the link breaks, it is an error). The
downside is that this would require parser support, since it is a
*syntax* model change and the !!tag isn't suppose to see stuff
like the anchor names. A possibility would be to add another
funny character to the list of indicators...
---
author: &author Bruce Williams
message: |*-
The *(author) wrote this.
Not exactly pretty. This feature is probably better done with a
specific type (perhaps using parenthesis on the type specifier to
give it arguments...).
I hope this helps. I don't think any one of these is a direct
action item that I'm comfortable with proposing. Does anyone else
in the gallery have ideas on this one?
Best,
Clark
|