From: Brian I. <in...@tt...> - 2002-09-07 06:29:57
|
On 06/09/02 18:32 +0000, Clark C . Evans wrote: > On Fri, Sep 06, 2002 at 01:34:08AM -0700, Brian Ingerson wrote: > | I want to address is a concern from Section 3 Information Models. > > The whole model section needs yet another wording pass to make > it more articulate; hopefully it doesn't need to be changed. FWIW I read the entire model section again today. It made my head hurt. I can barely understand the point(s) of its intention. Actually I can't understand it at all. Previously I've thought "Oh this is just Clark's area to be pedantic", but if I can't make heads or tails of it, perhaps we're not really on the same page. So enough whining from me. I'd really like to work with you on making this more useful. Let me know how I can help. > > | The spec talks about a process called a Viewer that "presents this native > | structure in a YAML-compatible way". The inferred reasoning is that a Loader > | would turn an event stream into a Native binding, and then a viewer would > | turn that into a Graph model or Uniform view; whatever you want to call it. > | Something that YPATH etc, could operate on. > > Right. > > | I think that's a bit backwards. I think that a Loader could definitely create > | a Generic view directly from an event stream without ever going all the way > | to Native. > > The loader could create a Native view which was exactly equivalent > to the Generic model so that the "view" is a no-op. This is explicitly > supported by the model as written and covered in our earlier discussion. A native view can only be created when: A) There are no application specific transfers involved or B) The loader can call into Application registered transfers One simple way to think conceptually about how a Loader would create the Native view is this: 1) The loader turns the event stream into a generic set of nodes with real aliases. 2) The loader calls the application registered transfer for each node that has a special transfer method URI, and replaces the original node with the new "native" one. > > | I also think that logically you always go through the generic model *before* > | getting to the native model. In order to get to Native, you often need to > | interact with the application class code. You need to call a registered > | classes' from_yaml() method, or whatever to create a native node. In my mind, > | what you pass that method is a generic node, that the application *transfers* > | into a Native node. > > Hmm. I think Oren and I were considering that the native > representation would be built before resolving aliases, and > thus would be created from the Serial model; hence the diagram. > Of course there isn't much difference beween the Serial and > the Generic node, other than the Serial node is a single-pass > sequential interface. This makes very little sense to me. > > | That's the way YAML.pm works. For anything node that has an explicit > | transfer, I create a generic node (using the YAML::Node module) and pass it > | to a yaml_load() method (my name for from_yaml). You end up with an API like > | this: > | > | native_node = ApplicationClass.yaml_load(generic_node) > | generic_node = ApplicationClass.yaml_dump(native_node) > | > | Now I don't create a generic node for plain strings, integers, hashes and > | arrays only as an optimization (perhaps premature ;). I certainly could. And > | I could also just load an entire graph of only generic (YAML::Node) nodes. > | This is what my YPATH implementation would work on. > > Nods. > > | So I see the diagram as being more like: > | > | SYNTAX <--> SERIAL <--> GENERIC <--> NATIVE > > Hmm. In the previous paragraph you seem to be saying... > > SYNTAX <--> SERIAL <--> NATIVE <-> GENERIC (optionally) > > No? No! That's what *you* seem to be saying :) It's very interesting that the spec lists the models as: - Native - Generic - Serial - Syntax And implies that that's how they flow. Well I totally agree for N->Y. So don't you see the obvious symetry of going Y->N? It's: - Syntax - Serial - Generic - Native > The GENERIC part only comes into play when you want > to use YPATH or other generic tools on an in-memory > representation not having aliases. I can see that you see it that way. But it's perfectly reasonable to conceptually think of the generic model always be created in full before the native. Most loaders will not deal fully with the serial and generic levels, but that does not mean that they are not there conceptually. It's much easier IMO to view YNY as: Syntax->Serial->Generic->Native->Generic->Serial->Syntax regardless of what optimizations your implementation might make. Cheers, Brian |