[Feature Request] Enhanced metadata for CRUD applications

Problem Statement

One common pattern is to have a dynamic list of items that the used can create, edit, and delete, and massive amounts of developer time still seems to go into these.

It would be very useful if a CRUD interface could be automatically generated from a card, and if the required metadata was standardized, so that everyone could share editable micro-formats.

This would be very useful in productivity-type applications, where one often wants to store large numbers of note types like calendar entries, notes, lists, etc.

It would also be useful in social and newsfeed like applications, enabling users to share a wide variety of content types.

One big advantage is that the available data modifications in the UI could be defined purely declaratively, and in a reusable way.

At the moment, it's possible to declaratively define the rendering of data, but anything more requires code, which is a potential security issue in any application that supports community plugins.

In addition, things like adding and removing items from lists currently require code, when they could conceivably be done declaratively.

Proposed solution

At it's most basic, for read-only use, cards would get three new keys. A globally unique ID for that card, a title, and a schema URI for the data type which the card was meant to render.

Having the title and ID would be useful as one data type may have many possible cards that could possibly render it, and the user may want to choose among them.

For the sake of standardization, perhaps licensing and author information would be useful to have.

This would allow documents(Such as in a news feed or similar) to tell the host what kind of card should be used to handle it(Perhaps embedding a $schema key in the document itself) and for the user to choose which plugins they would like to install to handle the various cards.

It would also simplify the process of automatically fetching a card from a repository to handle a given documents, providing a deterministic alternative to the template service analysis.

Going further, but perhaps slightly out of scope, a card could specify how to create datums of the type that it renders, and how to modify its own data.

An AEL-based template could describe how to modify a document given form data, and potentially an existing document.

For example, if you want to be able to set the start time of a meeting, you would just create an input with id "startTime", and define your "Modifying handler" as {"/startTime" : "${startTime}"}, essentially just a set of JSON pointers that set whatever they point to, to be

For semantics, a new action could be defined that represented a request to modify the data, which the host would then have to carry out(Since it does not appear that card objects are aware of the data used to process their templates).

It would be slightly messy, but even things like the classic shopping list app could be done with select actions and AEL modifications.

To create new objects, the card could define a sub-card used for creating things, which would use actions just like the modification transforms, using the sub card's $data as a starting point.

For deletion, a further new action could be added, or it could be entirely left to the host.

Other than creating the AEL-based transform language, it seems that the additional implementation complexity needed would be low.

I suspect pretty much everything could be done just by adding an applyTransform(old, inputs, transformDefinition) function, and documenting a few reserved keys in the card templates.

Alternatives or Workarounds

No response

No files, tests, or implementation entry points are identified in the issue. Start by reviewing the card templates and the proposed applyTransform(old, inputs, transformDefinition) function, then clarify the metadata and CRUD-action scope. Done would require an agreed specification before implementation can be assessed.