Comments (3)
selector_walk.json
needs just a little bit of explainer about which fields are what. (I grok this already; can draft this in a sec.)
ipld -> data in Json format being selected on
selector -> selector to apply on the data
expect_visit -> in order nodes visited applying the selector
on the ipld
selector_explore.json
... @austinabell may actually have to explain to me, I'm not sure I get that one :)
This is just testing the selector progression as it applies on the ipld. This is just testing the explore functionality when I was comparing against the go implementation (ie: https://github.com/ipld/go-ipld-prime/blob/08171d6bef3662ed7839e2c541f2c727d04e1c36/traversal/selector/exploreIndex.go#L23 but for each selector)
- I'm gonna need a little help understanding the
"cbor_ipld_storage"
field inselector_walk_links.json
as well.
These tests were more tailored to what I wanted to ensure worked for our client. Each item in that array is cbor encoded and put in a blockstore (and those are the links that are populated when traversing). Made most sense to me because this is the use case for most
Yeah sorry this isn't well documented, was on a time crunch, but hopefully the tests setup to be run by other implementations helps :) I just wanted to be able to ensure interoperability through setting this up
Explore runner is simple but the walking runner is here: https://github.com/ChainSafe/forest/blob/main/ipld/tests/walk_tests.rs
from specs.
A couple of misc things I'd like to see added along with those fixtures:
selector_walk.json
needs just a little bit of explainer about which fields are what. (I grok this already; can draft this in a sec.)- some of the entries in
selector_walk.json
touch on really fun things! Like, a few actually probe order stability. They don't comment this very loudly and a few more words might be good on that. selector_explore.json
... @austinabell may actually have to explain to me, I'm not sure I get that one :)- I'm gonna need a little help understanding the
"cbor_ipld_storage"
field inselector_walk_links.json
as well.
from specs.
Quick draft on explainer of selector_walk.json
's format ➡️
This fixture file contains a list of fixture objects.
Each fixture object matches the IPLD Schema:
type Fixture struct {
# "description" is free text describing the fixture.
description String
# "ipld" is a hunk of IPLD data that we'll apply a selector to.
# This data can really be anything (single string; ragged recursive structure; etc).
# (Since these fixtures are stored in json, it's really just more json
# structure continuing under this map key in the fixture.)
ipld Any
# "selector" is the encoded selector which we'll parse and apply to the data.
# (This matches the Selector schema, but here, let's skip details and call it "Any".)
selector Any
# "expect_visit" is a list of visit information, in order,
# which we'll expect the selector to yield when applied to the data.
expect_visit [VisitPoint]
} representation map
type VisitPoint struct {
# "path" is the path from root of the data up to this VisitPoint.
path Path
# "node" is a node (or at least a shorthand of it) reached at this point in a visit.
node VisitPointNode
# "matched" is true if the selector had a matcher clause hit this node;
# "matched" is false if the selector visited this node but didn't explicitly match on it.
matched Bool
} representation map
type Path string # a slash-delimited path between the root of the data (which has a path of empty string) and a VisitPoint.
type VisitPointNode any # we'll come back to this in a moment.
(Note: the schema is used here only for documentation! You don't need to implement IPLD Schemas in order to implement Selectors; in fact, these fixtures were developed without schemas, and I'm applying them retroactively as an explainer tool.)
To make this concrete, let's look at some JSON that matches this:
{
"description": "Walk matching simple node",
"ipld": "basic test",
"selector": {
".": {}
},
"expect_visit": [
{
"path": "",
"node": {
"string": "basic test"
},
"matched": true
}
]
}
Now let's look at VisitPointNode
a little more deeply.
VisitPointNode
's job is to describe what node in the original data has been reached during the selector's walk.
To do this, it says what kind the node is; and then -- only if it's a scalar -- it states the node's data.
(If it's a recurive -- like a map or a list -- a null is just used instead, because we don't want to repeat that much data.)
In schema form:
type VisitPointNode union {
| Bool "bool"
| Int "int"
| Float "float"
| String "string"
| Bytes "bytes"
| MapDummy "map"
| ListDummy "list"
| Link "link"
} representation keyed
type MapDummy unit representation null
type ListDummy unit representation null
The expect_visit
list is ordered, and exact. A selector should yield exactly this visit points, in exactly this order.
(In other words: Selector visitation orders are deterministic, and you should test for this.)
from specs.
Related Issues (20)
- graphsync spec - clarify relationships between libp2p connections, streams, messages and requests HOT 1
- Self describing objects in the data model layer HOT 2
- Defining Any and its behaviors HOT 13
- Endianness in IPLD Codecs HOT 2
- CBOR: Data model serialization in Rust HOT 22
- Invariants for IPLD Codecs HOT 3
- Define "component specifier" HOT 1
- Spec for inline CID’s
- Request: Magic AMT HOT 2
- Data model - Integer as map key HOT 5
- Representation of Infinity and NaN in DAG-JSON HOT 11
- Confusion about envelope (and inline) representation of unions HOT 5
- Best practices for IEEE-754 non-fintite numbers (NaN, Infinity) HOT 1
- Documentation about "context" HOT 1
- codec: pathed link HOT 9
- Data Model claims (erroneously?) that DAG-CBOR rejects integers outside of 64 bit range HOT 1
- Is the String kind conceptually a series of bytes or characters? HOT 15
- Why is the reified form of IPLD Schemas "generally presented as JSON" instead of IPLD itself? HOT 1
- Register MIME type application/car with IANA HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from specs.