# dog-and-duck.quack.picky documentation

## Generated by Codox

# Dog-and-duck 0.1.0-SNAPSHOT

# dog-and-duck.quack.picky

Fault-finder for ActivityPub documents.

Generally, each `-faults` function will return:

1. `nil` if no faults were found;
2. a sequence of fault objects if faults were found.

Each fault object shall have the properties:

1. `:@context` whose value shall be the URL of a document specifying this vocabulary;
2. `:type` whose value shall be `Fault`;
3. `:severity` whose value shall be one of `minor`, `should`, `must` or `critical`;
4. `:fault` whose value shall be a unique token representing the particular fault type;
5. `:narrative` whose value shall be a natural language description of the fault type.

Note that the reason for the `:fault` property is to be able to have a well known place, linked to from the @context URL, which allows narratives for each fault type to be served in as many natural languages as possible.

The idea further is that it should ultimately be possible to serialise a fault report as a document which in its own right conforms to the ActivityStreams spec.

### activitystreams-context-uri

The URI of the context of an ActivityStreams object is expected to be this literal string.

view source

### context?

`(context? x)`

Returns `true` iff `x` quacks like an ActivityStreams context, else false.

A context is either 1. the URI (actually an IRI) `activitystreams-context-uri`, or 2. a collection comprising that URI and a map.

view source

### filter-severity

`(filter-severity reports severity)`

Return a list of reports taken from these `reports` where the severity of the report is greater than this `severity`.

view source

### has-context?

#### macro

`(has-context? x)`

True if `x` is an ActivityStreams object with a valid context, else `false`.

view source

### make-fault-object

`(make-fault-object severity fault narrative)`

Return a fault object with these `severity`, `fault` and `narrative` values.

An ActivityPub object MUST have a globally unique ID. Whether this is meaningful depends on whether we persist fault report objects and serve them, which at present I have no plans to do.

view source

### object-faults

`(object-faults x)`

TODO: write docs

view source

### severity

Severity of faults found, as follows:

1. `:minor` things which I consider to be faults, but which don’t actually breach the spec;
2. `:should` instances where the spec says something SHOULD be done, which isn’t;
3. `:must` instances where the spec says something MUST be done, which isn’t;
4. `:critical` instances where I believe the fault means that the object cannot be meaningfully processed.

view source

### severity-filters

Hack for implementing a severity hierarchy

view source

### validation-fault-context-uri

The URI of the context of a validation fault report object shall be this literal string.

view source