Draft of CLI/API design #1

ribose-jeffreylau · 2025-01-22T06:43:57Z

This issue is to gather inputs from potential users of this tool.

Assuming the CLI is called doctl:

Initialize a documents register

> doctl init doc-reg-name
> ls
doc-reg-name/

Set register metadata

> cd doc-reg-name/
> doctl set name1 value1
> doctl set-add name1.ary1[] ary_value1
> doctl set-add name1.obj1.ary[] val1

Initialize dataset

A dataset groups together a set of documents.
It is up to the documents register user to decide which documents to be grouped as one.
One document can only belong to one dataset.

> cd doc-reg-name/
> doctl init-dataset my-documents

List datasets

> doctl ls
my-documents
...

Set dataset metadata

> cd doc-reg-name/
> doctl  set datasets.my-documents.meta.name1 value1
> doctl  set-add datasets.my-documents.meta.name1.ary1 ary_value1
> doctl  set-add datasets.my-documents.meta.name1.ary1 ary_value2
> doctl  get datasets.my-documents.meta.name1.ary1
ary_value1
ary_value2

Upload a new document

> doctl upload my-documents/UNIQUE_EXTERNAL_DOCUMENT_ID FILES...
> doctl upload my-documents/UNIQUE_EXTERNAL_DOCUMENT_ID [--status DOC_STATUS] FILES...

Under the hood, UNIQUE_EXTERNAL_DOCUMENT_ID will be modelled as an Item Class (ISO 19135).

Modify document metadata

> doctl set datasets.my-documents.UNIQUE_EXTERNAL_DOCUMENT_ID.status published
> doctl set datasets.my-documents.UNIQUE_EXTERNAL_DOCUMENT_ID.published_date $(date)

List document versions

> doctl ls-versions my-documents/UNIQUE_EXTERNAL_DOCUMENT_ID
...1
...2
...

List document files of a particular version

> doctl ls my-documents/UNIQUE_EXTERNAL_DOCUMENT_ID
...
main.pdf
...
> doctl ls my-documents/UNIQUE_EXTERNAL_DOCUMENT_ID#version_string
...
main.pdf
...

Add a new document version

> doctl upload my-documents/UNIQUE_EXTERNAL_DOCUMENT_ID FILES...

Override a document version

> doctl upload --force my-documents/UNIQUE_EXTERNAL_DOCUMENT_ID#VERSION_STRING FILES...

Remove a document version

> doctl rm my-documents/UNIQUE_EXTERNAL_DOCUMENT_ID#VERSION_STRING

Getting help

> doctl help
> doctl set help
> doctl ls help
> doctl upload help
> doctl rm help
> doctl init help
> doctl init-dataset help

The text was updated successfully, but these errors were encountered:

ronaldtse · 2025-01-23T00:30:23Z

What's the reason for a purpose specific CLI for documents? So I can't manage other types of content? That can't be right.

ronaldtse · 2025-01-23T00:39:28Z

The new ISO 19135 already provides the underlying model for concept class, concept, register item class and register item.

These are the concept classes to implement:

document (across stages but not across years)
document with stage
document with stage version

These are the register item classes to implement:

document
document with stage
document with stage version that includes the actual content

I.e you need to create data definitions for these things above.

We need a generic way of handling these, not hard coding their attributes in code.

Please refer to how data definitions are expressed and implemented in lutaml-model.

ribose-jeffreylau · 2025-01-23T01:14:34Z

What's the reason for a purpose specific CLI for documents? So I can't manage other types of content? That can't be right.

Bad name I guess. It's a temporary name. Lemme change that.

ribose-jeffreylau · 2025-01-23T05:00:24Z

What's the reason for a purpose specific CLI for documents? So I can't manage other types of content? That can't be right.

The new ISO 19135 already provides the underlying model for concept class, concept, register item class and register item.

These are the concept classes to implement:
* document (across stages but not across years)

* document with stage

* document with stage version
These are the register item classes to implement:
* document

* document with stage

* document with stage version that includes the actual content
I.e you need to create data definitions for these things above.

We need a generic way of handling these, not hard coding their attributes in code.

Please refer to how data definitions are expressed and implemented in lutaml-model.

Ruby Paneron Register currently only has concepts of register item class and register item, which as I understand, realize "concept classes" and "concepts" from ISO 19135.

If we want to keep the generality of the tools, my thoughts go to something like this:

> ctl --concept-model-map  ./document_with_stages_mapping_to_register_model.lutaml \
    init document_register
> cd document_register
> ctl --concept-model-map  ../document_with_stages_mapping_to_register_model.lutaml \
    init-dataset my-dataset
> ctl --concept-model-map  ../document_with_stages_mapping_to_register_model.lutaml \
    upload  my-dataset/Doc-00001 files...

Does this sound like the right direction?

EDIT: I am getting some similar vibe from here: lutaml/lutaml-model#165

ribose-jeffreylau · 2025-01-24T11:13:48Z

Further ideas & goals

The tool should be able to fetch external data models (on local disk / hosted on GitHub / etc.) that are specified on invocation (impl. details: cached, of course).
The data models should provide enough domain-specific information for the tool to:
- perform data input validation,
- present generic register items as domain-specific objects,
- provide domain-specific interactions with register items, item classes, metadata, etc.
  - That implies a need to define a mapping of such domain-specific actions to primitive register actions.
These data models should ideally be defined in terms of LutaML models.
The tool should aim to eliminate the need for the user to directly perform any further Git-related tasks (e.g., git tag) for the purpose of publishing documents, for example.

ribose-jeffreylau · 2025-02-18T06:40:50Z

The data models should provide enough domain-specific information for the tool to:

perform data input validation,

present generic register items as domain-specific objects,

provide domain-specific interactions with register items, item classes, metadata, etc.

That implies a need to define a mapping of such domain-specific actions to primitive register actions.

These data models should ideally be defined in terms of LutaML models.

These issues may make defining register data models easier:

ribose-jeffreylau · 2025-02-18T10:34:23Z

The data models should provide enough domain-specific information for the tool to:

perform data input validation,

present generic register items as domain-specific objects,

provide domain-specific interactions with register items, item classes, metadata, etc.

That implies a need to define a mapping of such domain-specific actions to primitive register actions.

These data models should ideally be defined in terms of LutaML models.

Brainstorming how a data model definition may look like:

---
register:
  concepts:
    - name: Document
      attributes:
        id:
          definition: The unique identifier of the document
          type: string
        year:
          definition: The year the document was published
          type: year
        doctype:
          definition: The Metanorma document type
          type: string
        doc_class:
          definition: The Metanorma document class
          type: string
      relations:
        - target: DocumentStage
          relationship:
            source:
              type: aggregation
              attributes:
                document:
                  cardinality:
                    min: 1
                    max: "*"
            target:
              type: direct
              attributes:
                documentStage:
                  cardinality:
                    min: 1
                    max: "*"
            action:
              verb: comprises
              direction: target
    - name: DocumentStage
      attributes:
        stage:
          definition: The stage of the document
          type: string
      relations:
        - target: DocumentVersion
          relationship:
            source:
              type: aggregation
              attributes:
                documentStage:
                  cardinality:
                    min: 1
                    max: "*"
            target:
              type: direct
              attributes:
                documentVersion:
                  cardinality:
                    min: 1
                    max: "*"
            action:
              verb: comprises
              direction: target
    - name: DocumentVersion
      attributes:
        version:
          definition: The version of the document
          type: string
  data:
    item_classes:
      values: null # No concrete item classes, since we are sorting by Document ID
      # register items with the same Document ID will be grouped together
      # in an item class
      group_by:
        name: Document
        attribute: id
      sort_by:
        attribute: year
        order: desc
    register_items:
      attributes:
        # Here, we map each register item attribute to the corresponding concept
        id:
          definition: The document identifier
          concept: Document
          attribute: id
        stage:
          definition: The stage of the document
          concept: DocumentStage
          attribute: stage
        version:
          definition: The version of the document
          concept: DocumentVersion
          attribute: version
        year:
          definition: The year the document was published
          concept: Document
          attribute: year
        title:
          definition: The title of the document
          type: string
  actions:
    # Here, list out the actions that can be performed on the
    # item classes and register items,
    # and map them to the corresponding functions...
    - name: create_document_version
      use: create_register_item
      parameters:


# ... TBD

ribose-jeffreylau · 2025-02-19T03:50:18Z

I think it is worthwhile to brainstorm some possible concrete interactions before hashing out the full data models, to get a better sense of the requirements:

> export CTL_DATA_DEFINITION=github:CalConnect/register-data-model    # remote
# or
> export CTL_DATA_DEFINITION=/home/username/register-data-model     # local
> ctl create_document_version my-data-set/cc-10001:2022 ./compiled/artifacts/cc-10001-2022/
Using data definition from github:CalConnect/register-data-model...
You are creating a new "document version".
(keys: <esc> to go back one step, <enter> to continue)

# A note on the default values provided: these could be configured
# to be parsed from the documents to be uploaded, e.g. to specify that
# document.rxl be read (via a programmatic API)
Input "id" (default: cc-10001:2022): <enter>
Input "stage" (<space> to select):
o published
o final-draft
x draft
Input "version" (default: 1): <enter>
Input "year" (default: 2022): <enter>
Input "title" (default: CalConnect Directive: Standardization and publication): <enter>
Confirm the following details
(keys: <esc> to go back one step, <enter> to continue)
id: cc-10001:2022
stage: draft
version: 1
year: 2022
title: CalConnect Directive: Standardization and publication
continue? <enter>
Copying 4 files...  done
Creating commit in register... done
Syncing... done
Summary
- A new document version has been created (my-data-set/cc-10001:2022).

ribose-jeffreylau · 2025-02-19T03:59:12Z

Overwriting an existing version:

> export CTL_DATA_DEFINITION=github:CalConnect/register-data-model
> ctl create_document_version my-data-set/cc-10001:2022 ./compiled/artifacts/cc-10001-2022/
Using data definition from github:CalConnect/register-data-model...
You are creating a new "document version".
(keys: <esc> to go back one step, <enter> to continue)
Input "id" (default: cc-10001:2022): <enter>
Input "title" (default: CalConnect Directive: Standardization and publication): <enter>
Confirm the following details
Input "year" (default: 2022): <enter>
Input "stage" (<space> to select):
o published
o final-draft
x draft

# The "version" field follows the auto-increment rule defined in the data model,
# which now provides an updated default value.
Input "version" (default: 2): 1<enter>
(keys: <esc> to go back one step, <enter> to continue)
id: cc-10001:2022
title: CalConnect Directive: Standardization and publication
year: 2022
stage: draft
version: 1
continue? <enter>
*** A "document version" with the same metadata already exists.
*** Overwrite? (Y/n) Y <enter>
Copying 4 files...  done
Creating commit in register... done
Syncing... done
Summary
- A "document version" has been overwritten (my-data-set/cc-10001:2022).

Listing document versions:

> export CTL_DATA_DEFINITION=github:CalConnect/register-data-model
> ctl list_document_versions my-data-set/cc-10001:2022
Using data definition from github:CalConnect/register-data-model...
Listing all "document version" for (my-data-set/cc-10001:2022)...
cc-10001:2022, CalConnect Directive: Standardiz..., 2022, draft, 1, cc10001-2022.pdf, cc10001-2022.rxl, ...
Summary
- 1 "document version" found for (my-data-set/cc-10001:2022).

List document versions (with multiple results):

> export CTL_DATA_DEFINITION=github:CalConnect/register-data-model
> ctl list_document_versions my-data-set/cc-10002:2019
Using data definition from github:CalConnect/register-data-model...
Listing all "document version" for (my-data-set/cc-10002:2019)...
cc-10002:2019, CalConnect Directive: Standard d..., 2019, draft, 1, cc10002-2019.pdf, cc10002-2019.rxl, ...
cc-10002:2019, CalConnect Directive: Standard d..., 2019, draft, 2, cc10002-2019.pdf, cc10002-2019.rxl, ...
cc-10002:2019, CalConnect Directive: Standard d..., 2019, draft, 3, cc10002-2019.pdf, cc10002-2019.rxl, ...
cc-10002:2019, CalConnect Directive: Standard d..., 2019, draft, 4, cc10002-2019.pdf, cc10002-2019.rxl, ...
cc-10002:2019, CalConnect Directive: Standard d..., 2019, draft, 5, cc10002-2019.pdf, cc10002-2019.rxl, ...
cc-10002:2019, CalConnect Directive: Standard d..., 2019, draft, 6, cc10002-2019.pdf, cc10002-2019.rxl, ...
cc-10002:2019, CalConnect Directive: Standard d..., 2019, final-draft, 1, cc10002-2019.pdf, cc10002-2019.rxl, ...
cc-10002:2019, CalConnect Directive: Standard d..., 2019, final-draft, 2, cc10002-2019.pdf, cc10002-2019.rxl, ...
cc-10002:2019, CalConnect Directive: Standard d..., 2019, final-draft, 3, cc10002-2019.pdf, cc10002-2019.rxl, ...
cc-10002:2019, CalConnect Directive: Standard d..., 2019, published, 1, cc10002-2019.pdf, cc10002-2019.rxl, ...
cc-10002:2019, CalConnect Directive: Standard d..., 2019, published, 2, cc10002-2019.pdf, cc10002-2019.rxl, ...
Summary
- 11 "document version" found for (my-data-set/cc-10002:2019).

List document versions with filtering:

> export CTL_DATA_DEFINITION=github:CalConnect/register-data-model
> ctl list_document_versions my-data-set/cc-10002:2019 stage:published
Using data definition from github:CalConnect/register-data-model...
Listing all "document version" for (my-data-set/cc-10002:2019)...
cc-10002:2019, CalConnect Directive: Standard d..., 2019, published, 1, cc10002-2019.pdf, cc10002-2019.rxl, ...
cc-10002:2019, CalConnect Directive: Standard d..., 2019, published, 2, cc10002-2019.pdf, cc10002-2019.rxl, ...
Summary
- 2 "document version" found for (my-data-set/cc-10002:2019).

Removing a document version (by default selects the last version):

> export CTL_DATA_DEFINITION=github:CalConnect/register-data-model
> ctl delete_document_version my-data-set/cc-10001:2022
Using data definition from github:CalConnect/register-data-model...
You are deleting a "document version" (my-data-set/cc-10001:2022).
(keys: <esc> to go back one step, <enter> to continue)
id: cc-10001:2022
title: CalConnect Directive: Standardization and publication
year: 2022
stage: draft
version: 1
continue? <enter>
Removing 4 files...  done
Creating commit in register... done
Syncing... done
Summary
- A "document version" has been deleted (my-data-set/cc-10001:2022).

Removing a specific document version with filtering:

> export CTL_DATA_DEFINITION=github:CalConnect/register-data-model
> ctl delete_document_version my-data-set/cc-10002:2019 stage:published
Using data definition from github:CalConnect/register-data-model...
You are deleting a "document version" (my-data-set/cc-10002:2019).
(keys: <esc> to go back one step, <enter> to continue)
id: cc-10002:2019
title: CalConnect Directive: Standard and documents
year: 2019
stage: published
version: 2
continue? <enter>
Removing 4 files...  done
Creating commit in register... done
Syncing... done
Summary
- A "document version" has been deleted (my-data-set/cc-10002:2019).

> export CTL_DATA_DEFINITION=github:CalConnect/register-data-model
> ctl delete_document_version my-data-set/cc-10002:2019 stage:published
Using data definition from github:CalConnect/register-data-model...
You are deleting a "document version" (my-data-set/cc-10002:2019).
(keys: <esc> to go back one step, <enter> to continue)
id: cc-10002:2019
title: CalConnect Directive: Standard and documents
year: 2019
stage: published
version: 1
continue? <enter>
Removing 4 files...  done
Creating commit in register... done
Syncing... done
Summary
- A "document version" has been deleted (my-data-set/cc-10002:2019).

Removing a non-existent document version:

> export CTL_DATA_DEFINITION=github:CalConnect/register-data-model
> ctl delete_document_version my-data-set/cc-10001:2022 version:3
Using data definition from github:CalConnect/register-data-model...
You are deleting a "document version" (my-data-set/cc-10001:2022).
Error: There is no existing "document version" with the following metadata.  Aborting.
id: cc-10001:2022
version: 3
Summary
- No "document version" has been deleted (my-data-set/cc-10001:2022).

List all documents:

> export CTL_DATA_DEFINITION=github:CalConnect/register-data-model
> ctl list_documents my-data-set
Using data definition from github:CalConnect/register-data-model...
Listing all "document" from data set (my-data-set)...
cc-10001:2022, CalConnect Directive: Standardiz..., 2022, draft, 1, cc10001-2022.pdf, cc10001-2022.rxl, ...
cc-10002:2019, CalConnect Directive: Standard d..., 2019, published, 1, cc10002-2019.pdf, cc10002-2019.rxl, ...
Summary
- 2 "document" found for data set (my-data-set).

Show details of a specific document version:

> export CTL_DATA_DEFINITION=github:CalConnect/register-data-model
> ctl show_document_version my-data-set/cc-10002:2019
Using data definition from github:CalConnect/register-data-model...
Select the "document version" for (my-data-set/cc-10002:2019)...
(<space> to select):
o cc-10002:2019, CalConnect Directive: Standard d..., 2019, draft, 1, cc10002-2019.pdf, cc10002-2019.rxl, ...
o cc-10002:2019, CalConnect Directive: Standard d..., 2019, draft, 2, cc10002-2019.pdf, cc10002-2019.rxl, ...
o cc-10002:2019, CalConnect Directive: Standard d..., 2019, draft, 3, cc10002-2019.pdf, cc10002-2019.rxl, ...
o cc-10002:2019, CalConnect Directive: Standard d..., 2019, draft, 4, cc10002-2019.pdf, cc10002-2019.rxl, ...
o cc-10002:2019, CalConnect Directive: Standard d..., 2019, draft, 5, cc10002-2019.pdf, cc10002-2019.rxl, ...
o cc-10002:2019, CalConnect Directive: Standard d..., 2019, draft, 6, cc10002-2019.pdf, cc10002-2019.rxl, ...
x cc-10002:2019, CalConnect Directive: Standard d..., 2019, final-draft, 1, cc10002-2019.pdf, cc10002-2019.rxl, ...
o cc-10002:2019, CalConnect Directive: Standard d..., 2019, final-draft, 2, cc10002-2019.pdf, cc10002-2019.rxl, ...
o cc-10002:2019, CalConnect Directive: Standard d..., 2019, final-draft, 3, cc10002-2019.pdf, cc10002-2019.rxl, ...
o cc-10002:2019, CalConnect Directive: Standard d..., 2019, published, 1, cc10002-2019.pdf, cc10002-2019.rxl, ...
o cc-10002:2019, CalConnect Directive: Standard d..., 2019, published, 2, cc10002-2019.pdf, cc10002-2019.rxl, ...
id: cc-10002:2019
title: CalConnect Directive: Standard document requirements
year: 2019
stage: final-draft
version: 1
artifacts:
  - cc10002-2019.html
  - cc10002-2019.pdf
  - cc10002-2019.rxl
  - cc10002-2019.xml

Download artifacts for a specific document version (from a remote source):

> export CTL_DATA_DEFINITION=github:CalConnect/register-data-model
> ctl get_document_version github:CalConnect/cc-document-register#my-data-set/cc-10002:2019
Using data definition from github:CalConnect/register-data-model...
Using remote register from github:CalConnect/cc-document-register...
Select the "document version" for (my-data-set/cc-10002:2019)...
(<space> to select):
o cc-10002:2019, CalConnect Directive: Standard d..., 2019, draft, 1, cc10002-2019.pdf, cc10002-2019.rxl, ...
o cc-10002:2019, CalConnect Directive: Standard d..., 2019, draft, 2, cc10002-2019.pdf, cc10002-2019.rxl, ...
o cc-10002:2019, CalConnect Directive: Standard d..., 2019, draft, 3, cc10002-2019.pdf, cc10002-2019.rxl, ...
o cc-10002:2019, CalConnect Directive: Standard d..., 2019, draft, 4, cc10002-2019.pdf, cc10002-2019.rxl, ...
o cc-10002:2019, CalConnect Directive: Standard d..., 2019, draft, 5, cc10002-2019.pdf, cc10002-2019.rxl, ...
o cc-10002:2019, CalConnect Directive: Standard d..., 2019, draft, 6, cc10002-2019.pdf, cc10002-2019.rxl, ...
x cc-10002:2019, CalConnect Directive: Standard d..., 2019, final-draft, 1, cc10002-2019.pdf, cc10002-2019.rxl, ...
o cc-10002:2019, CalConnect Directive: Standard d..., 2019, final-draft, 2, cc10002-2019.pdf, cc10002-2019.rxl, ...
o cc-10002:2019, CalConnect Directive: Standard d..., 2019, final-draft, 3, cc10002-2019.pdf, cc10002-2019.rxl, ...
o cc-10002:2019, CalConnect Directive: Standard d..., 2019, published, 1, cc10002-2019.pdf, cc10002-2019.rxl, ...
o cc-10002:2019, CalConnect Directive: Standard d..., 2019, published, 2, cc10002-2019.pdf, cc10002-2019.rxl, ...
id: cc-10002:2019
title: CalConnect Directive: Standard document requirements
year: 2019
stage: final-draft
version: 1
artifacts:
  - cc10002-2019.html
  - cc10002-2019.pdf
  - cc10002-2019.rxl
  - cc10002-2019.xml
Save files to (default: .)? <enter>
Copying 4 files...  done
Summary
- 4 "artifacts" items for a "document version" have been downloaded (github:CalConnect/cc-document-register#my-data-set/cc-10002:2019).

Show all available actions (as defined by the data definition):

> export CTL_DATA_DEFINITION=github:CalConnect/register-data-model
> ctl help
Using data definition from github:CalConnect/register-data-model...
Available actions:
- create_document_version
  parameters:
    - item_class_path
    - id (default: parsed from item_class_path)
    - title (default: parsed from rxl file in item_class_path)
    - year (default: parsed from rxl file in item_class_path)
    - stage (default: parsed from rxl file in item_class_path)
    - version (default: auto-increment)
    - artifacts (type: file list)
- delete_document_version
  parameters:
    - item_class_path
    - id (default: parsed from item_class_path)
    - title (default: parsed from rxl file in item_class_path)
    - year (default: parsed from rxl file in item_class_path)
    - stage (default: parsed from rxl file in item_class_path)
    - version (default: last, sorted in ascending order)
- get_document_version
  parameters:
    - item_class_path
    - id (default: parsed from item_class_path)
    - title (default: parsed from rxl file in item_class_path)
    - year (default: parsed from rxl file in item_class_path)
    - stage (default: parsed from rxl file in item_class_path)
    - version (default: last, sorted in ascending order)
  returns:
    - artifacts
- list_document_versions
  parameters:
    - item_class_path
  returns:
    - list of document version items
- list_documents
  parameters:
    - data_set_path
  returns:
    - list of document items
- show_document_version
  parameters:
    - item_class_path
    - id (default: parsed from item_class_path)
    - title
    - year
    - stage
    - version
  returns:
    - details of a document version item
- add_artifacts
  parameters:
    - item_class_path
    - id (default: parsed from item_class_path)
    - title
    - year
    - stage
    - version
    - artifacts (type: file list)
- delete_artifacts
  parameters:
    - item_class_path
    - id (default: parsed from item_class_path)
    - title
    - year
    - stage
    - version
    - filename of artifacts (type: string list)

Another register might have a different set of actions:

> export CTL_DATA_DEFINITION=github:isogr/register-data-model
> ctl help
Using data definition from github:isogr/register-data-model...
Available actions:
- create_proposal
  parameters:
    - title
  returns:
    - id of proposal
- delete_proposal
  parameters:
    - id of proposal
- remove_from_proposal
  parameters:
    - id of proposal
    - list of item_path
- submit_proposal
  parameters:
    - id of proposal
- approve_proposal
  parameters:
    - id of proposal
- reject_proposal
  parameters:
    - id of proposal
- create_extent
  parameters:
    - id of proposal
    - name
    - ...
  returns:
    - id of extent
- create_transformation
  parameters:
    - id of proposal
    - id of extent
    - name
    - ...

ronaldtse · 2025-02-19T18:13:52Z

@ribose-jeffreylau I've written up a specification for the CLI here. Let me know what you think?

https://github.com/paneron/docs/blob/main/sources/paneron-cli.adoc

ribose-jeffreylau · 2025-02-20T03:04:05Z

Just thought about it, it probably makes more sense to have the first command as the type of object and then put the action after, so an order of: type of object, verb, arguments.

Originally posted by @ronaldtse in #3

ribose-jeffreylau added the question Further information is requested label Jan 22, 2025

ribose-jeffreylau mentioned this issue Jan 22, 2025

Management and rendering of documents and artifacts CalConnect/cc-documents-register#4

Open

This was referenced Feb 18, 2025

Add documentation on usage #4

Open

Plan: Use register-ctl (hence ruby-paneron-register) to manage documents artifacts CalConnect/standards.calconnect.org#64

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Draft of CLI/API design #1

Draft of CLI/API design #1

ribose-jeffreylau commented Jan 22, 2025 •

edited

Loading

ronaldtse commented Jan 23, 2025

ronaldtse commented Jan 23, 2025

ribose-jeffreylau commented Jan 23, 2025

ribose-jeffreylau commented Jan 23, 2025 •

edited

Loading

ribose-jeffreylau commented Jan 24, 2025 •

edited

Loading

ribose-jeffreylau commented Feb 18, 2025

ribose-jeffreylau commented Feb 18, 2025

ribose-jeffreylau commented Feb 19, 2025 •

edited

Loading

ribose-jeffreylau commented Feb 19, 2025 •

edited

Loading

ronaldtse commented Feb 19, 2025 •

edited by ribose-jeffreylau

Loading

ribose-jeffreylau commented Feb 20, 2025

Draft of CLI/API design #1

Draft of CLI/API design #1

Comments

ribose-jeffreylau commented Jan 22, 2025 • edited Loading

Initialize a documents register

Set register metadata

Initialize dataset

List datasets

Set dataset metadata

Upload a new document

Modify document metadata

List document versions

List document files of a particular version

Add a new document version

Override a document version

Remove a document version

Getting help

ronaldtse commented Jan 23, 2025

ronaldtse commented Jan 23, 2025

ribose-jeffreylau commented Jan 23, 2025

ribose-jeffreylau commented Jan 23, 2025 • edited Loading

ribose-jeffreylau commented Jan 24, 2025 • edited Loading

Further ideas & goals

ribose-jeffreylau commented Feb 18, 2025

ribose-jeffreylau commented Feb 18, 2025

ribose-jeffreylau commented Feb 19, 2025 • edited Loading

ribose-jeffreylau commented Feb 19, 2025 • edited Loading

ronaldtse commented Feb 19, 2025 • edited by ribose-jeffreylau Loading

ribose-jeffreylau commented Feb 20, 2025

ribose-jeffreylau commented Jan 22, 2025 •

edited

Loading

ribose-jeffreylau commented Jan 23, 2025 •

edited

Loading

ribose-jeffreylau commented Jan 24, 2025 •

edited

Loading

ribose-jeffreylau commented Feb 19, 2025 •

edited

Loading

ribose-jeffreylau commented Feb 19, 2025 •

edited

Loading

ronaldtse commented Feb 19, 2025 •

edited by ribose-jeffreylau

Loading