Review of Indy HIPE #0149: Rich Schema Schemas about indy-hipe HOT 12 OPEN

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.

from indy-hipe.

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.

from indy-hipe.

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

from indy-hipe.

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.

from indy-hipe.

when creating txnId, is the marker value 8?

from indy-hipe.

@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.

from indy-hipe.

@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.

from indy-hipe.

@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.

from indy-hipe.

@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.

from indy-hipe.

• 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.

from indy-hipe.

@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.

from indy-hipe.

@burdettadam

when creating txnId, is the marker value 8?

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

from indy-hipe.