From: Clark C. E. <cc...@cl...> - 2006-03-29 06:31:34
|
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 |