Note that #48 is focused on generating from JSON-LD contexts (read-in). This will focus on the backend part: once a vocabulary is read in, how to generate it into go-fed. Another issue (#66) will then work on designing a solution to allow pluggable vocabularies without bloating activity/pub.
In this case, the existing tooling needs to:
associate a context string with the vocabulary,
output the vocabulary to a different folder,
use a flag to regenerate only specific vocabularies (convenience),
generate its own Resolver type
generate its own Vocabulary master type (see related issue #66)
EDIT: Note that vocabularies will need to be plugged-in to each other as well. This will be handled by the vocab package for those that don't want to rely on pub. If this is not done, then core Activity types won't be able to deserialize into extended types, and vice versa. Which is a silly limitation to have.
Note that #48 is focused on generating from JSON-LD contexts (read-in). This will focus on the backend part: once a vocabulary is read in, how to generate it into go-fed. Another issue (#66) will then work on designing a solution to allow pluggable vocabularies without bloating
activity/pub
.In this case, the existing tooling needs to:
string
with the vocabulary,Resolver
typeVocabulary
master type (see related issue #66)EDIT: Note that vocabularies will need to be plugged-in to each other as well. This will be handled by the
vocab
package for those that don't want to rely onpub
. If this is not done, then coreActivity
types won't be able to deserialize into extended types, and vice versa. Which is a silly limitation to have.