Skip to content

Should Vault allow retrieval of "legacy" services by id, type? #9

Description

@tomcrane

This is one of a few issues raised by experimenting with vault for this: https://tomcrane.github.io/scratch/cp/tree.html

vault.get({id, type}) won't recover an ImageService2 or a SearchService1 because they have @id and @type, even in the normalised P3 representation. Should Vault be forgiving and still allow you to obtain this, e.g., vault.get("id": "https://example.org/my-image-service", "type": "ImageService2") ?

Vault shouldn't attempt to "normalise" ImageService2 to 3 or anything like that - it's an external service, out of vault's normalisation remit. But you might be in a scenario where you don't know what id and type are, or don't want to have special cases in the code.

More controversial - while Vault should be able to recover a @id resource from the value of that property, or a {id,type} ref, should it extend the returned resource with id and type if it has @id and @type (and as long as it doesn't already have id or type properties? This would make for simpler code, e.g.,

const someService = vault.get(serviceId);
if(someService.type === "ImageService2"){
   // do some imagey thing
}

...instead of testing for .type and ["@type"] all the time.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions