Repository navigation
token relationship modeling in the XML #114
Description
Three relationships to start with
depend: the token is valid only of the depended token is valid (belong to the current user)
decorate: the token provides additional attributes or modifies existing attributes. Usually, this is done by having an attestation to go with the token, but there may be cases where the attestation isn't issued by the token issuer (e.g. for a book token, purchase-date which might be different than the transaction date, is attested by the different guy than title), and therefore might use a different Tokenscript, leading to the situation of a decorative tokenscript.
possess: the token has another token as its component
P.S. Attribute-type's mapping can grow complicated as possible values become growable. If it is only the growth of a look-up table, this would be done by upgrading TokenScript, but it's possible that the mapping uses smart contract sources, e.g. the attribute being hat and the token being cryptokitten, where the hat's ID is a token in another smart contract. Such cases are usually better handled with token relationships. But if there are cases that should not be handled with token relationship,
Activity
[-]namespace http://tokenscript.org/2019/05/tokenscript[/-][+]schema changes for namespace http://tokenscript.org/2019/05/tokenscript[/+][-]schema changes for namespace http://tokenscript.org/2019/05/tokenscript[/-][+]token relationship modeling in the XML[/+]hboon commentedon Apr 23, 2019
Relationships are important, but do we need it soon or is this for planning? In case we don't have something immediate to test the design with.
overseers-desk commentedon Apr 23, 2019
We don't need it in the next 4 months:) But I struggle a bit to prevent this scenario: when we release a proper implementation for relationships, it begets changes (like a change to the parent node) of
<contract>element that requires rewriting of older TokenScripts. I'll keep this open as a thinkpadhboon commentedon Apr 23, 2019
Ah. Certainly makes sense to design them first then. Internally it might be more manageable, but anything written by others would be harder to communicate. And tutorials.