Weekly design meeting #17 + #18

Tokenscript Design
1

I merged the meetings during Chrismas time. We had only 3 people showing up during Chrismas (and I bailed out in the meeting before Christmas holiday time. Sorry).

Agenda being discussed in the #17 and #18 meetings.

  • A URI schema for attestation (documented A URI schema for attestations - if you have suggestions please do it asap as we are turning that disdcussion result into a spec)
  • Conceptually separate the <card> (UI and enclave) elements from the rest of the declarative / data components, and calling the former module and the later schema. (Proposed by Zaki)
  • How to identify objectClass (for data-objects). Only draft ideas discussed.

James Zaki asked for a clarification of the TokenScript file structure so far, after the 2019 meetings, so that in 2020 any new comer to TokenScript can have a status-quo understanding of the current TokenScript structure.

I compiied with it by providing this

A typical TokenScript starts

<token>
  <contract name="...">
    <address>....</address>

Then the object-classes

Followed by object-class. object-class is the definition of data objects, just like attribute-type are the definition of attributes. I'm careful not to name the class / type definition the same as the things they defined. I also use id="xxx" over name="xxx" to let developers not confuse it with <name>.

    <object-class id="ticket">
      <sequence>
       <element name=”numero” type=”asn:Integer”/>
       <element name=”class”>
         <type><enumerated>
           <enumeration name=”normal” number=”0"/>
           <enumeration name=”gift” number=”1"/>
           <enumeration name=”VIP” number=”2"/>
         </enumerated></type>
       </element>
       <element name=”start” type=”asn:UTCTime”/>
      </sequence>
    </object-class>
    <object-class id="ticketRedeemed">
      ...
    </object-class>
    <object-class id="ticketTraded">
      ....
    </object-class>
  </contract>

Followed by attributes definition

  <attribute-type id="expiry">
    <name>
      <string xml:lang="en-US">Expiration</string>
      <string xml:lang="en">Expiry</string>
      <string xml:lang="zh">过期日</string>
    <origns>
        <ethereum function="redeemed" contract="unicon" as="bool">
            <data>
                <uint256 ref="tokenId"/>
            </data>
        </ethereum>
    </origins>
  </attribute-type>
  <attribute-type id="class">
    <name>...</name>
    <origins>
      <attestation object-class="ticket">
        <filter>....</filter>
        ...
      </attestation>
    ...
 </attribute-type>

The above examplified the definition of two attribute-types. One is originated from a call to an Ethereum smart contract (has to be view or pure), while the other originates from the attestation defined in the first object-class. There are usually 10+ attributes for a token (excpet 2017's ICO tokens which are dumb in general).

Then it's followed by transaction declarations which are needed for DvP security. Since we haven't started designing syntax for DvP security I'll omit it here.

Then you get to the cards. James Zaki proposed "schema" vs "module" can be roughly mapped to "everything before this point" and "everythign after this point".

  <cards>
    <token-card>
      <style>...</style>
      <view>...</view>
      <view-iconified>...</view-iconified>
   </tokne-card>

Where HTML code is in the <view>. There will be <audible> in parallel with <view> in the likely event that HTML's accessibility design not up-to-par (there are 3 reasons why it may happen).

And action cards

    <action>
      <name>...</name>
      <style>...</style>
      <view>...</view>
      <view-iconified>...</view-iconified>
      <transaction>...</transaction>
    </action>
  </cards>
</token>

I didn't demonstrate <order> and <grouping> as they are optional.

Note that in all TokenScripts so far, <cards> are defined before <attribute-type>, not after, but following James Zaki's idea of separating the data layer and the UI stuff, I change the schem and all tokenscripts so that <attribute-type> appears before <action> in the Jan-2020 schema.

1 Like