From: Oren Ben-K. <or...@ri...> - 2002-05-07 06:45:12
|
Brian Ingerson [mailto:in...@tt...] wrote: > I thought it might be useful to start keeping track of the > multitudes of models (or states or layers or whatever) that > are potentially involved in processing YAML. Good idea. > --- !!glossary > SF: Syntax Formatting (indentation, comments,...) > KO: Map Key Order > AN: Anchor & Alias Names > NK: Node Kind > NT: Node Type Family > NF: Node Format > NC: Node Content > > --- !!models > - model: Syntax > info: [ SF, KO, AN, NK, NT, NF, NC ] > consumers: [ Tokenizer ] > producers: [ Formatter ] Right. > - model: Token > info: [ KO, AN, NK, NT, NF, NC ] > consumers: [ Parser ] > producers: [ Emitter ] I guess so. > - model: Tree > info: [ KO, AN, NK, NT, NF, NC ] > consumers: [ Filter ] > producers: [ Filter ] What is "Filter"? Shouldn't it be: consumers: [ Loader ] producers: [ Dumper ] Instead? Otherwise it doesn't connect with: > - model: Graph > info: [ NK, NT, NF, NC ] > consumers: [ Loader, YPATH ] > producers: [ Dumper ] - Replace "YPATH" with "YAML Tools" in general. - Whether or not NF/NK is there is still very much TBD... It may be that in the graph model we only have NT and NCC (Node Canonical Content). > - model: Native > info: [] > consumers: [ User Application ] > producers: [ User Application ] I don't think "info: []" is a fair description. Each node (implicitly) contains NT and NCC. This demonstrates why I tend to want the graph model to contain just NT and NCC - it makes it possible to treat the graph model as a view of the native model: making the implicit info explicit, but not adding any additional concepts. This enables implementing a "YAML view" adaptor code which attaches to existing data structures and allows applying YAML level tools to them, without having to maintain extra state per node for NF, NK, NC etc. At any rate, the above formulation is great in clarifying and talking about the issues. Thanks! Have fun, Oren Ben-Kiki |