## [Yaml-core] Damn Pretty (Was:Re: our information model: a typed graph)

 [Yaml-core] Damn Pretty (Was:Re: our information model: a typed graph) From: Clark C . Evans - 2001-11-11 01:44:58 ```On Sat, Nov 10, 2001 at 08:47:05PM -0500, Clark C . Evans wrote: | The information model of YAML is a typed *graph*, | where each node can be one of three kinds, | - scalar (having no arrows) | - sequence (having an ordered set of unlabeled arrows) | - map (having an unordered set of labeled arrows) | and a type (which is an identifier unique in its context). Speaking of which... perhaps this isn't quite the right information model. Maybye it's simpler. The information model of YAML is a typed graph with labeled arrows. Yes. This is it. A sequence is just syntax sugar for a map with integer keys! This also fits in with Brian's sparce list idea. How cool. Thus, --- - a - b - c Is short hand for... --- !list 0: a 1: b 2: c Damn Pretty. I think I'm going to cry. Best, Clark ```

 [Yaml-core] our information model: a typed graph From: Clark C . Evans - 2001-11-11 01:35:08 ```I want to get back to our original information model. The information model of YAML is a typed *graph*, where each node can be one of three kinds, - scalar (having no arrows) - sequence (having an ordered set of unlabeled arrows) - map (having an unordered set of labeled arrows) and a type (which is an identifier unique in its context). IMHO, if we loose this information model, we loose YAML... it only becomes a good serialization langauge and will fail as an information processing language... The goal is to have all kinds of wonderful graph transformations worked out algorithmically with pretty math proofs (this is going to be the next many years for me... after our language is set). So. That said. Let's get back to the model. I don't think that 'alias' is a type (or color) it is the sequential linking mechanism which enables the "graph" word in the model above. It's very special -- just like map and sequence. ... For "pretty printing" each scalar node can have a "style", but this style is part of the serialization mechanism and not part of the inforamtion model -- if it gets lost it *won't* change the nature of the data. Throw-away comments are in the same category. Now, there is nothing being said that these can't be preserved or round-tripped. But round tripping them is not high priority. And, since we are serializing into a tree structure, we have to introduce anchors and references to those anchors (alias). But which nodes have anchors and which do not and which are references in the serialization is *not* part of the information model. Only the information encoded by those anchors and references are part of the information model. Also, what is *not* part of the core information model is what the "types" mean. Of course we can standardize many YAML types to allow for various processing applications, but this isn't part of the core information model. Thus, one of these types can be a "pointer", but in this regard, a pointer is an application defined type and it is not part of the graph structure (although if you notice, to use a pointer so that the node can appear twice in the graph an alias is needed; thus anchors and alias). Does this make sense? Sorry if I sound like I'm flipping... but it just dawned on me that our information model changed when I wasn't looking and I'm not so happy. The *graph* part of this information model is very important to me. Ok. It's been fun. We're rockin' Best, Clark ```
 [Yaml-core] Damn Pretty (Was:Re: our information model: a typed graph) From: Clark C . Evans - 2001-11-11 01:44:58 ```On Sat, Nov 10, 2001 at 08:47:05PM -0500, Clark C . Evans wrote: | The information model of YAML is a typed *graph*, | where each node can be one of three kinds, | - scalar (having no arrows) | - sequence (having an ordered set of unlabeled arrows) | - map (having an unordered set of labeled arrows) | and a type (which is an identifier unique in its context). Speaking of which... perhaps this isn't quite the right information model. Maybye it's simpler. The information model of YAML is a typed graph with labeled arrows. Yes. This is it. A sequence is just syntax sugar for a map with integer keys! This also fits in with Brian's sparce list idea. How cool. Thus, --- - a - b - c Is short hand for... --- !list 0: a 1: b 2: c Damn Pretty. I think I'm going to cry. Best, Clark ```
 Re: [Yaml-core] Damn Pretty (Was:Re: our information model: a typed graph) From: Clark C . Evans - 2001-11-11 03:04:49 ```On Sat, Nov 10, 2001 at 08:56:46PM -0500, Clark C . Evans wrote: | Speaking of which... perhaps this isn't quite the | right information model. Maybye it's simpler. | | The information model of YAML is a typed | graph with labeled arrows. | | Yes. This is it. A sequence is just syntax sugar | for a map with integer keys! This also fits in | with Brian's sparce list idea. How cool. Thus, | | --- | - a | - b | - c | | Is short hand for... | | --- !list | 0: a | 1: b | 2: c Why is this neat? 0. It's clean. And a colored graph with labeled arrows is a well known mathematical construct. Thus, we ain't re-inventing the wheel. 1. When I was designing the API, I had the problem of distinguishing between maps and lists. Beacuse a list item didn't have a key. But, on the other hand, I thought that the parser *knows* which item it's on... so there isn't a reason why it shouldn't report the index as the key. This cleans things up very well; it's obvious now that the API should report the list index as the "label" for the given node. 2. This may help clean up the productions. Now there could be two "core" productions, "branch" and "scalar". I'll have to investigate this. If it messes things up... there is nothing saying we have to complicate our BNF syntax... 3. It means that there is one less construct that a target language must support; they need only support a map and scalar. An array becomes an efficient native encoding, much like integers can be stored and operated on as int32 instead of strings. 4. We've talked about other syntaxes for describing deep content. I'm not sure, but if the list mechanism was sort-of-like an implicit type; perhaps we could add other implicit types that produce graphs. table: +-------+---------+------------ |Family |Given |Telephone +-------+---------+------------ |Smith |Jonathan |202.544.7328 |Edwards|Martha |293.288.2834 could be equivalent to... table: !list 0: Family: Smith Given: Jonathan Telephone: 202.544.7328 1: Family: Edwards Given: Martha Telephone: 293.288.2834 And... Perhaps this is taking things a bit too far, but I wonder... perhaps not. This might even clean up the core productions. Thus... If it starts with a "-" it is a list, if the content starts with a "+" it is a table. Otherwise normal content scanning is used. Hmmms... Clark ```
 [Yaml-core] Re: our information model: a typed graph From: Brian Ingerson - 2001-11-11 04:17:11 ```On 10/11/01 20:47 -0500, Clark C . Evans wrote: > I want to get back to our original information model. > > The information model of YAML is a typed *graph*, > where each node can be one of three kinds, This is the kind of stuff I like you and Oren to argue about. I'm just a plain old JAPH. If it works for Perl in the end, I'm happy. If not, then we have a problem. Cheers, Brian ```