Extension mechanism(s)

[kcoyle]

There will be a need to extend TAP. There are a range of details that would encompass "extension". A minimum extension would be to simply allow any columns with unknown column headers to be passed through to the program output. A maximum extension would allow the addition of columns with their value constraints to be defined.

Along with the definition of the level of extension detail there is where the extension will take place, aka what is the mechanism? - whether it means modifying the dctap-python program, or whether the extension can be done through a table or configuration file that doesn't require program modification (for at least the simpler cases?).

There are probably other considerations, so please add them as well as comment on the general concepts.

[kcoyle]

I should add that one of the "mechanisms" is to create TAP-XL - a version of TAP with elements that are frequently needed - things like min/max values, severity of errors, string lengths, open/close shapes. That doesn't solve the local extensions issue, but could reduce the need for local extensions for these common needs.

[tombaker]

@kcoyle

A minimum extension would be to simply allow any columns with unknown column headers to be passed through to the program output. ... whether the extension can be done through a table or configuration file that doesn't require program modification (for at least the simpler cases?).

The very latest dctap-python supports configuration-file sections for adding extra shape elements and extra statement constraint elements, so it does what you propose above.

I should add that one of the "mechanisms" is to create TAP-XL - a version of TAP with elements that are frequently needed - things like min/max values, severity of errors, string lengths, open/close shapes.

There could be a section of the Primer for naming and describing extra headers or value constraint types. We could perhaps let these bubble up from users for awhile.

For example, @nishad and @philbarker have suggested encouraging users to write scripts that import and extend (eg, with subclasses) the base module dctap-python. This would allow the base module to remain generic, based just on modules from the Python standard library, without increasing its dependency load with imported modules for ShEx, SHACL, XML, or whatever. Such external modules would likely include language-specific extensions. We could then compare these and pull the most common into a TAP-XL.

[kcoyle]

These are the main focus of the cookbook.