You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note: this URL is not currently live; but the fragment is well-formed in the current execution system, where the documents are provided to the lookup machinery for JSD schemas.
In a given loom graph extension environment, there will be some family of nodes and annotations defined. The validation of node and annotation types, and other machinery which we wish to associate with these types, is independent of the identification of the types.
It is a design goal to be able to extend identification to safe namespaces, presumably namespaced by common names associated with an extension dialect's domain; but also to namespaces which derive from a given generation environment, possibly with a UUID or hash namespace.
This task is to investigate other URI/URN schemes, to act as an extensible namespace for identifying types, with the goal that it is easy to bind handlers for those types in a given LoomEnvironment.
The text was updated successfully, but these errors were encountered:
Currently, loom types are identified by URLs pointing to Json Schema Document fragments.
For example: http://tensortapestry.org/schemas/loom/2024-01/node_types.jsd#/nodes/Tensor
In a given loom graph extension environment, there will be some family of nodes and annotations defined. The validation of node and annotation types, and other machinery which we wish to associate with these types, is independent of the identification of the types.
It is a design goal to be able to extend identification to safe namespaces, presumably namespaced by common names associated with an extension dialect's domain; but also to namespaces which derive from a given generation environment, possibly with a UUID or hash namespace.
This task is to investigate other URI/URN schemes, to act as an extensible namespace for identifying types, with the goal that it is easy to bind handlers for those types in a given LoomEnvironment.
The text was updated successfully, but these errors were encountered: