address #630 #638
address #630 #638
Conversation
I'm not entirely satisfied with the addition in common/terms.html, as it seems too detailed for the terminology section. But... ...as pointed out in the comment of #630, the API spec references to this definition in multiple places, and many of those links are actually for instances of the internal representation, *not* for instances of the strings or maps that represent term definition in JSON. So the alternative would be to introduce a new name for those "internal term definition" and patch all the algorithms... which seems laborious and error-prone. @gkellogg I don't remember what's the process for synchronizing the files in common with other specs.
Just needs to be copied. The GH Action checks out common and compares the results. |
Co-authored-by: Ted Thibodeau Jr <[email protected]>
|
This one probably also needs to be formatted as a candidate amendment... |
I didn't follow the pattern 'change_N' for the id, because this change will also be present in json-ld-syntax (in comment/terms), and so will probably require a candidate addition in that spec too (with a different index). Hence the more robust id used here.
| <ins cite="#change_api_638"><br/> | ||
| For <a data-cite="JSON-LD11-API#context-processing-algorithms">context processing</a>, <a>term definition</a> values are converted internally to a dedicated data structure that is easier to process.</ins> |
There was a problem hiding this comment.
The problem with this is that that will show up in syntax and framing, as well.
There was a problem hiding this comment.
yes, that's why I named it change_api_638 insteal of change_8. That way, we can add a change marker in the other specs without an ID clash.
There was a problem hiding this comment.
We'll need issues for those other specs to have their own version of this update.
There was a problem hiding this comment.
Co-authored-by: Ted Thibodeau Jr <[email protected]>
I'm not entirely satisfied with the addition in common/terms.html, as it seems too detailed for the terminology section. But...
...as pointed out in the comment of #630,
the API spec references to this definition in multiple places, and many of those links are actually for instances of the internal representation, not for instances of the strings or maps that represent term definition in JSON.
So the alternative would be to introduce a new name for those "internal term definition" and patch all the algorithms... which seems laborious and error-prone.
@gkellogg I don't remember what's the process for synchronizing the files in common with other specs.
Preview | Diff