CIP-0100: The example.json file is missing required fields

[Crypto2099]

CIP-0100 includes an example.body.json file: available here.

This file is currently missing two required fields which are: hashAlgorithm and authors. Hash Algorithm is required as a string set to blake2b-256 and the authors array must be present even if empty.

@Ryun1 is the latest culprit in the git blame game :)

[Ryun1]

example.body.json just contains the body, so shouldnt have the hashAlgorithm and authors

the full example file is example.json

the .body is just a intermediate file which I kept as i think it may help explain the steps

[Crypto2099]

Why does the body file have the "@context" in that case?

[Crypto2099]

I will cede that the examples in CIP-0100 are confusing, but the one and only example in CIP-0119 is definitely missing the authors field :)

https://github.com/cardano-foundation/CIPs/blame/master/CIP-0119/examples/drep.jsonld

[Ryun1]

and only example in CIP-0119 is definitely missing the authors field :)

I think this should be changed because its confusing, but;
witnesses

[gitmachtl]

CIP-0008 -> CIP-0030

[Crypto2099]

@Ryun1 you guys randomly removed a required field higher up in the hierarchy? What is the point if we are not inheriting properties from earlier/other models and everything is going to have a custom schema?

[Ryun1]

@Ryun1 you guys randomly removed a required field higher up in the hierarchy? What is the point if we are not inheriting properties from earlier/other models and everything is going to have a custom schema?

Im not an author on this one, I was very against doing this
as you say, its a mess and confusing not to inherit

[rphair]

I recall we kept trying to put forward schema.org as a model, including its inheritance mechanism, as a model for governance metadata properties... and recall it was deemed "something for future improvement" in meeting discussion. I've searched for the relevant GitHub discussions a bit this evening (to no avail, thanks to GitHub collapsing all conversations: looking again for a workaround for this) with nothing yet.

At this point, how could / how would we go about mandating inheritance for these properties? Would such a change be worth bearing some unpleasant side effects now, with the goal of a less error-prone system in the long run? cc @Quantumplation

https://schema.org/docs/datamodel.html

[Quantumplation]

There is no "inheeritence", because extensions to the standard shouldn't be thought of as overriding CIP-100;

When you specify your context, you are layering the fields that you include; A document can have a context that includes references to CIP-100, AND CIP-119, AND mySelfHostedDomain.com/myCustomContext, and reference schema.org, etc.

So, CIP-119 can define new fields; or even redefine fields that it thinks are defined incorrectly in another CIP, but it shouldn't be thought of as superseding a previous CIP.

If anything, CIP-100 should be updated to slightly relax it's requirement: "Tooling authors should warn if the CIP-100 authors field is present but empty, or has invalid signatures"; and then, optionally, CIP-119 could define it's own authors field with new semantics (i.e. DON'T warn if it's absent, treat this as coauthors, etc.).

Then, the context of the documents you produce would just specify that the definition of authors you're using is from CIP-119., or omit it completely.

[Crypto2099]

Again, I'm not really sure what benefit we've derived in this case from JSON-LD as now we have an anti-standard that is convoluted and complex to implement with no clear benefit over regular JSON fields since every schema must be explicitly documented because we're ignoring inheritance (prevalent in other implementations of JSON-LD such as schema.org as mentioned by @rphair) and continually suggesting that everyone can just include whatever they want and hope for the best from explorers in the future. No wonder the display and formatting of data is a mess and inconsistent across the ecosystem.

[Quantumplation]

We're not ignoring inheritance, I'm not sure why you think that.

Users of CIP-119 can inherit fields from CIP-100 just fine.

The breakdown seems to be in thinking of CIP-119 as a replacement for CIP-100, which attempts to supersede or change the definitions in CIP-100; We should look at why they felt the need to do this, which is the UX concern around having to collect two signatures: one for the transaction, and one for the authors field, and that points to an oversight in CIP-100, which is worth addressing IMO.

[Quantumplation]

The comparison to schema.org is a bit misplaced; JSON-LD is less about the types and more about the definitions.

The JSON-LD specifies how to uniquely identify and interpret a field; this is slightly different than defining a type system, which is what JSON Schema / RDF Schema / etc. do.

I kept butting my head up against this too when trying to write CIP-100, as I kept looking for ways to express, in the JSON-LD context itself, that something was a string, or an object with certain fields, etc.

Now, part of the definition of how to interpret a field may also include the schema that you can expect and rely on; In fact, this is why a .schema.json file is included in CIP-0100. But JSON-LD itself isn't designed for that purpose, and trying to force it into that hole will lead to pain, IMO.