Overview

Based on this readme listing I'm adding feedback based on existent implementations and expected lib user competencies (as we target many almost non-tech users - publisher, data wranglers etc).

use frictionlessdata\datapackage;

// register custom datapackage or resource classes which can override / extend core classes
// these custom classes run a test against the schema to decide whether to handle a given descriptor or not
Factory::registerDatapackageClass("my\\custom\\DatapackageClass");
Factory::registerResourceClass("my\\custom\\ResourceClass");

// register custom profiles and related schemas for validation
Registry::registerSchema("my-custom-profile-id", "path/to/my-custom-profile.schema.json");

Profiles handling

Just want to share how we handle it in Python/Javascript. After all back and forth with profiles on specs and libs level for now we have a simple system for main libs (and Ruby is syncing). It's described here - https://github.com/frictionlessdata/datapackage-rb/issues/31#issuecomment-310603664- and based on descriptor.profile which could be:

profile id
profile url

That's the very lightweight approach which could be considered instead of registering classes/jsonschemas etc (which could be like too difficult for ordinary users if I've got current API correctly)

Schema term

Minor thing (if naming could be minor) but across all implementations we're leaning toward following terminology:

schema - Table Schema
profile - JSON Schema to validate descriptor
jsonschema - profile representation as a dict/object

frictionlessdata / datapackage-php

Profile API feedback #20

Overview

Profiles handling

Schema term