Re: [Yaml-core] YAML.rb 0.42 -- YPath and YamlNode

[Clark C. E. <cc...@cl...>]

On Mon, Sep 16, 2002 at 03:10:33PM -0600, why the lucky stiff wrote:
| The new YamlNode object is similiar to a DOM API.  The API 
| mirrors the Loading API.
| 
|                                   Loading (native)      Parsing (generic)
|                                   --------------------  --------------------
|       Single-document quickie     YAML::load            YAML::parse
|       Multiple document iterator  YAML::load_documents  YAML::parse_documents
|       Stream loader               YAML::load_stream     (Not yet available)

| The Parsing functions return a tree of YamlNodes to operate upon.  These nodes
| are basically classes with a 'type_id' property and a 'value' property.  
| In other words, it's all '!map', '!seq' and '!str' data with the transfer
| method attached.

_why this is great.   In the diagram Brian and Oren and I've been toying
with we've broken the YAML stages into three distinct processes:


   syntax   ->   serial   ->   graph   ->   native
        [parser]      [builder]     [loader]

   syntax   <-   serial   <-   graph   <-   native
        [emitter]    [serializer]    [dumper]

The parser handles the syntax and presents it as a sequence of events
(or with a pull-based iterator).   The builder constructs a random-access
version of the parse tree by resolving anchors/aliases and building the
mapping and sequence objects.   And the loader resolves data types into
their native bindings.   Emitter, Serializer, and Dumper do the
exact opposite processes.

So... I was thinking that your "parse" method wouldn't be better
represented with a "build" method.  In this way, you can have
the "parse" method return a sequential iterator - so the user 
need not have the entire YAML graph in memory at once.

...

Also.  I now think (thanks to Steve) that our current graph model 
"artifically" limits syntax level attributes in the serial and 
graph stages -- this is the more pragmatic message in Steve's 
argument which I think most of us agree.   So, perhaps you may also
have an option to even include key order, style, anchor name, and
other presentation orented properties to your YamlNode.

However, if you do this; it'd be great if we thought hard about
some way to signify that these additional properties are indeed 
"presentation" properties and should not be used for "essential"
data content.  Perhaps calling it PresentationOrder, etc. would
work, or perhaps having a sub-object "presentation".  I just don't
know -- it's definately your show.  I'd just like a cute 
reminder here and again that these buggers, as convienent as they
may be, won't be supported by our core toolset, and if used
in a non-presentation way could hinder interoperability.  *wheu*

| YPath is also now introduced!  We pass about half the tests right now. 

Oh.  You are copying the Ypath in the PyYaml distribution?  If so,
I'm totally flattered.  In any case, we should probably try to 
formalize this tool so that we get general buy-in.   I meant the
Ypath in PyYaml as only a experiment... to spark discussion.

Anyway.  There are two ways that the experimental YPath differs 
from XPath:

  1.  Since we have a graph, the path really returns
      an arrow (a series of nodes from the root to the tip).
      This is necessary since a node may be in more than
      one spot, so its meaning may depend upon how you got
      to it.   Of course, a user of Ypath can discard the
      path and just use the "tip" of the arrow.

      I see you clearly support both methods.  Hurray!


  2.  Since we have a functional model, a explict ypath
      can only return one node (*wheu*).  This is a great
      simplification... and will turn out to be very very
      cool down the road [I started on a CYATL]

I'd love to hear more about your visions for Ypath.  I have a very
"broad" idea, but this is definately something that will be best
evolved if everyone has a chance to state their ideas..

Way, Way, cool.

Best,

Clark