-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add cryptosuiteString
subtype for the cryptosuite
property.
#162
Conversation
@@ -235,7 +235,7 @@ property: | |||
- id: cryptosuite | |||
label: Cryptographic suite | |||
domain: sec:DataIntegrityProof | |||
range: xsd:string | |||
range: sec:cryptosuiteString |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is not correct in the vocabulary: the value of range
must be a class or a new datatype. Do we really want to go down the (tedious!) process of formally define a new datatype for cryptosuiteString
?
I would propose to leave the range a string, and add a comment (or part of the cryptosuite
property definition in the spec) what the constraints on the value are. But do not treat it as a datatype with a separate URL.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to add to my previous remark. If the WG does decide to define a new datatype, what I would think we should do is as follows.
- I do not think we should bother extending the yml2vocab script to add a datatype definition feature in general; this is a very rare occurrence, and this tool is not aimed at being a universal RDF tool. Also, the datatype definition is not part of the RDF Vocabulary Graph, in other words, it is not something we would add to the Turtle and JSON-LD files, only the HTML version. As a consequence, what I would propose to do is to add the formal definition to the integrity spec (see below), and add a separate section into the Template html file that refers back to the definition in the integrity spec, a bit like all the others. I am happy to do that, once the references in the integrity spec is available.
- The formal definition of a datatype requires the formal definition of the lexical space, value space, etc. Even for a type that is relatively simple it is, as I said, tedious. I think the formal definition of the rdf:JSON Datatype is a good example for what should be added to the integrity spec (probably in a normative appendix, to avoid breaking the flow of the main text).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we really want to go down the (tedious!) process of formally define a new datatype for cryptosuiteString?
Yes, we do, because if we don't do that, the resolution of using long cryptosuite names falls apart due to the burden it places on low-bandwidth environments. In other words, the pain felt in defining a new type will be on the Editors. If we don't define this type, the pain felt will be on every implementer out there in a low bandwidth environment. I'll volunteer to define the data type, thanks for the pointer to rdf:JSON... we'll model it after that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we do, because if we don't do that, the resolution of using long cryptosuite names falls apart due to the burden it places on low-bandwidth environments. In other words, the pain felt in defining a new type will be on the Editors. If we don't define this type, the pain felt will be on every implementer out there in a low bandwidth environment. I'll volunteer to define the data type, thanks for the pointer to rdf:JSON... we'll model it after that.
Fine. Then let us do it, but we should follow something like #162 (comment) to make it proper. It is tedious but not too much after all; the only important point is to define more formally the subset of strings that can be used as a datatype value. The rest is obvious (and the rdf:JSON stuff could indeed be used as a pattern).
I am o.k. to expand the formal vocabulary with the datatype stuff once the core spec has it, either in this PR or (probably better) in another one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Requesting a re-review from @TallTed as well because I added a bunch of text that's hard to read and I need his help to make it suck less. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Re-reviewed. Not too horrible. Editorial changes requested.
Co-authored-by: Ted Thibodeau Jr <[email protected]>
f1b58c8
to
bd6e1d6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Purely editorial: I have the strange feeling of a circular specification. The
cryptosuiteString
definition refers to thedataIntegrityProof
section, which then refers to thecryptosuiteString
section... And I did not see anywhere a clear specification (or reference to it) of the fact that cryptosuites have an identifier in terms of an ASCII string, and those are the ones we are talking about. At present, this datatype looks much more mysterious than what it is... But I may have missed some details. - For the records and to other reviewers: the
cryptosuiteString
datatype definition will be added to the vocabulary in a separate PR once this one settles. The reason for the delay is that the ability to add a datatype specification required an extension of the underlyingyml2vocab
tool and, although that extension is already done, it has not yet uploaded to the npm repository.
index.html
Outdated
<dt>The lexical space</dt> | ||
<dd> | ||
is the set of all cryptosuite types expressed using American Standard Code | ||
for Information Interchange [[ASCII]] strings that are defined by the sum of all |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder whether term "union" is not better than "sum" ("union" in the sense of a Union datatype in programming languages).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, "union" is clearly better, applied in a commit below.
@@ -235,7 +235,7 @@ property: | |||
- id: cryptosuite | |||
label: Cryptographic suite | |||
domain: sec:DataIntegrityProof | |||
range: xsd:string | |||
range: sec:cryptosuiteString |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Re-reviewed. Not too horrible. Editorial changes requested.
index.html
Outdated
<dt>The lexical space</dt> | ||
<dd> | ||
is the set of all cryptosuite types expressed using American Standard Code | ||
for Information Interchange [[ASCII]] strings that are defined by the sum of all |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for Information Interchange [[ASCII]] strings that are defined by the sum of all | |
for Information Interchange [[ASCII]] strings that are defined by the union of all |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Normative, multiple reviews, changes requested and made, no objections, merging. |
This PR is an attempt to address issue #161 by adding a
cryptosuiteString
subtype for thecryptosuite
property to ensure that it is possible to compress cryptosuite strings when performing semantic compression (CBOR-LD).Preview | Diff