Review of Indy HIPE #0149: Rich Schema Schemas

[burdettadam]

I have a few initial questions.

• It is unclear to me who is creating the schema @id, the client or server? Should the @id be included in the txn set request? If so, the rich schema example is missing an @id key in the data.schema dict. I think the @id needs to be created by the client because the client signs the txn before it is sent. If the server creates the @id and appends it into the schema, the signature for the data being stored in the rocks DB will be different than the original signed data in the txn, which does not feel right to me.
• Is txnId in the set response the same thing as @id?
• txnId in set response has the form of L5AD5g65TDQr1PPHHRoiGf1|recipeIngredient|1.0 , with '|' as the delimiter while the current txnIds have ':' as the delimiter, for example, FC4aWomrA13YyvYC1Mxw7:3:CL:14:some_tag. Is there a good reason to break up continuity and use '|' instead of ':'?

[burdettadam]

what is the schema of a txnId? Does this support tags as in other txnId?
for example,
L5AD5g65TDQr1PPHHRoiGf1|recipeIngredient|1.0
vs
L5AD5g65TDQr1PPHHRoiGf1|recipeIngredient|1.0|someTag.

[burdettadam]

I think a note should be added around indy_parse_GET_RICH_SCHEMA_response needing to support JSON-LD and custom-defined JSON-LD types.

[burdettadam]

• in meta block of the txn, should type be excluded since it is another form of the 201 txn.type?

[burdettadam]

I think get_rich_schema should take the schema @id as the parameter to retrieve the rich schema instead of a dest, name, version (, tag?).
Forcing the client to keep track of dest, name, version (, tag?) just so those values can be used to recreate the id on the server-side is not user-friendly and may cause client code to parse an @id to retrieve them. I understand they are separated so they could be used as search queries on the ledger, but this functionality is not present and there is no published timeline to build out such functionality.

[burdettadam]

when creating txnId, is the marker value 8?

[ken-ebert]

@burdettadam

• It is unclear to me who is creating the schema @id, the client or server? Should the @id be included in the txn set request? If so, the rich schema example is missing an @id key in the data.schema dict. I think the @id needs to be created by the client because the client signs the txn before it is sent. If the server creates the @id and appends it into the schema, the signature for the data being stored in the rocks DB will be different than the original signed data in the txn, which does not feel right to me.

The client should create the '@id'. The schema creation (SET_RICH_SCHEMA) should include the '@id'. The example should be modified to reflect this.

[ken-ebert]

@burdettadam

• Is txnId in the set response the same thing as @id?
  No. The 'txnId' is independent of the '@id'. The 'txId' is whatever the ledger wants to use to identify the transaction on the ledger.

• txnId in set response has the form of L5AD5g65TDQr1PPHHRoiGf1|recipeIngredient|1.0 , with '|' as the delimiter while the current txnIds have ':' as the delimiter, for example, FC4aWomrA13YyvYC1Mxw7:3:CL:14:some_tag. Is there a good reason to break up continuity and use '|' instead of ':'?

'txnId's are not specified by this HIPE.

[ken-ebert]

@burdettadam

what is the schema of a txnId? Does this support tags as in other txnId?
for example,
L5AD5g65TDQr1PPHHRoiGf1|recipeIngredient|1.0
vs
L5AD5g65TDQr1PPHHRoiGf1|recipeIngredient|1.0|someTag.

I believe your question is, "Should tags be supported?" Current schemas do not appear to support tags. We do not anticipate adding them to rich schema schemas.

[ken-ebert]

@burdettadam

I think a note should be added around indy_parse_GET_RICH_SCHEMA_response needing to support JSON-LD and custom-defined JSON-LD types.

We will add a note.

[ken-ebert]

• in meta block of the txn, should type be excluded since it is another form of the 201 txn.type?

Type is being included to support future discoverability functionality.

[ken-ebert]

@burdettadam

I think get_rich_schema should take the schema @id as the parameter to retrieve the rich schema instead of a dest, name, version (, tag?).
Forcing the client to keep track of dest, name, version (, tag?) just so those values can be used to recreate the id on the server-side is not user-friendly and may cause client code to parse an @id to retrieve them. I understand they are separated so they could be used as search queries on the ledger, but this functionality is not present and there is no published timeline to build out such functionality.

Agreed. The client could be simplified by allowing the rich-schema schema to be retrieved by the '@id' value instead of dest, name, version.

[ken-ebert]

@burdettadam

when creating txnId, is the marker value 8?

8 would follow the existing pattern as the next available marker for rich-schema schemas.