Content-Type: multipart/alternative; 
	boundary="----=_Part_299_15244383.1333034947728"

------=_Part_299_15244383.1333034947728
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

I've been playing around with implementation of a very simplistic YPath lib 
for Ruby. It's nothing anyone would consider conforming to a definitive 
YPath spec. Rather, it's just so there is at least something that basically 
works so I can use it with YES schema project. In other words I am throwing 
together a hack as a stand in until a *real* YPath library comes along. -- 
I so wish there was already a YPath library out there I could use.

In any case, working on this I realize that any YPath spec that's more or 
less patterned after XPath (which always seems to be the idea) is going to 
have some limitations. An obvious example is a YPath for mapping keys of 
some odd type. That makes me suspect of the the whole idea of an XPath-like 
YPath. So, what if YPath where just a YAML document with "match slots"? 
e.g. given a YAML document

    ---
    a: 1
    b: 2

YPath document:

    --- !ypath
    a: <?>

Then in code something like:

   ypath = YPath.new(ypath_document)
   ypath.match(yaml_document)

The return value would be a list containing 1 or the YAML node for 1.

Nod sure to search every node though (rather than just root), maybe 
something like

    --- !ypath-any
    a: <?>

Or

    --- !ypath
    <*>:
      a: <?>

Thoughts?


------=_Part_299_15244383.1333034947728
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

I've been playing around with implementation of a very simplistic YPath lib=
 for Ruby. It's nothing anyone would consider conforming to a definitive YP=
ath spec. Rather, it's just so there is at least something that basically w=
orks so I can use it with YES schema project. In other words I am throwing =
together a hack as a stand in until a *real* YPath library comes along. -- =
I so wish there was already a YPath library out there I could use.<br><br>I=
n any case, working on this I realize that any YPath spec that's more or le=
ss patterned after XPath (which always seems to be the idea) is going to ha=
ve some limitations. An obvious example is a YPath for mapping keys of some=
 odd type. That makes me suspect of the the whole idea of an XPath-like YPa=
th. So, what if YPath where just a YAML document with "match slots"? e.g. g=
iven a YAML document<br><br>&nbsp;&nbsp;&nbsp; ---<br>&nbsp;&nbsp;&nbsp; a:=
 1<br>&nbsp;&nbsp;&nbsp; b: 2<br><br>YPath document:<br><br>&nbsp;&nbsp;&nb=
sp; --- !ypath<br>&nbsp;&nbsp;&nbsp; a: &lt;?&gt;<br><br>Then in code somet=
hing like:<br><br>&nbsp;&nbsp; ypath =3D YPath.new(ypath_document)<br>&nbsp=
;&nbsp; ypath.match(yaml_document)<br><br>The return value would be a list =
containing 1 or the YAML node for 1.<br><br>Nod sure to search every node t=
hough (rather than just root), maybe something like<br><br>&nbsp;&nbsp;&nbs=
p; --- !ypath-any<br>
&nbsp;&nbsp;&nbsp; a: &lt;?&gt;<br>
<br>Or<br><br>&nbsp;&nbsp;&nbsp; --- !ypath<br>&nbsp;&nbsp;&nbsp; &lt;*&gt;=
:<br>&nbsp;&nbsp; &nbsp;&nbsp; a: &lt;?&gt;<br>

<br>Thoughts?<br><br>
------=_Part_299_15244383.1333034947728--