Page MenuHomeSoftware Heritage

docs/persistent-identifiers: Add guidelines for fixing invalid SWHIDs.
AbandonedPublic

Authored by vlorentz on Apr 12 2021, 4:46 PM.

Details

Summary

This is going to be implemented in swh-web, so we should codify this,
for implementations that want to be 'quirk-compatible' with ours.

As agreed in T3234.

Diff Detail

Repository
rDMOD Data model
Branch
master
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 20648
Build 32042: Phabricator diff pipeline on jenkinsJenkins console · Jenkins
Build 32041: arc lint + arc unit

Event Timeline

Build is green

Patch application report for D5485 (id=19616)

Rebasing onto f2dba177ad...

Current branch diff-target is up to date.
Changes applied before test
commit fab4f35044cdb5f3a90a50147ab41370f3806d42
Author: Valentin Lorentz <vlorentz@softwareheritage.org>
Date:   Mon Apr 12 16:46:10 2021 +0200

    docs/persistent-identifiers: Add guidelines for fixing invalid SWHIDs.
    
    This is going to be implemented in swh-web, so we should codify this,
    for implementations that want to be 'quirk-compatible' with ours.

See https://jenkins.softwareheritage.org/job/DMOD/job/tests-on-diff/309/ for more details.

move from 'Implementation' section to 'Interoperability'.

Build is green

Patch application report for D5485 (id=19617)

Rebasing onto f2dba177ad...

Current branch diff-target is up to date.
Changes applied before test
commit 81a810d17d92b991301423b0e7e99d15b2ffd957
Author: Valentin Lorentz <vlorentz@softwareheritage.org>
Date:   Mon Apr 12 16:46:10 2021 +0200

    docs/persistent-identifiers: Add guidelines for fixing invalid SWHIDs.
    
    This is going to be implemented in swh-web, so we should codify this,
    for implementations that want to be 'quirk-compatible' with ours.

See https://jenkins.softwareheritage.org/job/DMOD/job/tests-on-diff/310/ for more details.

I think we should rather encourage to validate input SWHIDs and report errors instead of automatically fixing them,
I will update D5484 in that manner.

We could point to the adequate function and classes in swh-model to do that in Python code.

For frontend code, we could create a small npm package to validate a SWHID.

Ok, so no need to change the specification document for SWHIDs.

Abandoning, as it was decided to validate instead of fixing automatically