Caveat: the "description" property is probably wrong; it should match the definition of the ActivityPub(!) "source" property which is currently not in go-fed.
This was a fucking nightmare, as expected. All because the PublicKey
type is not really a derivation of the ActivityStreams "Object", which I
had been hackily relying on for things to inherit the JSONLD "id" and
"type" properties.
This breaks the "id" and "type" JSONLD properties into first-class
properties known within the tool, which for now is a patchy job of duct
tape to cover the leaks.
If someone wants "PublicKey" to have more default supported properties,
I will kindly ask them to fork a code generation that suits them. This
took way too much effort to treat PublicKey like a grab bag.
This isn't the fix for, but is on the road to fixing, the known bug
about aggressive deserialization of "PublicKey" into other types. In
fact, this is on the way to *correctly* fix it without a horrible patch
in the generated code (imagine being hacky in []jen.Code{...}, that's
too much poo to put into the meta code).
The things I do to support incomplete ontologies and major Federation
players that, for whatever reason on this god-forsaken planet, decided
to adopt the ontology and type everything except "PublicKey" (I don't
count "endpoints" because that is a pile of steaming poo for another
different reason in addition to this one, and is completely optional).
No longer create "default aliases" for JSON-LD vocabularies. This would
break compatibility since the way JSON-LD propagates aliases is pushed
downwards, and not propagated upwards. Since a lot of implementations
don't actually care about JSON-LD, do a lot of hacking to make sure that
others that expect hardcoded contexts and the like will still be able to
handle our output.
Still need to hook together the "well known alias" so it can generate
contexts that match the community, but that will be for things like the
custom mastodon and litepub extensions.
I don't want to ever have to work with JSON-LD in a static language ever
ever again. This is shit code.
- Deserialization now happens correctly into the rdf:langString
property.
- Kluges to make sure the member is being set and referred to in the
generation code.
- No longer generate special member for natural language map nor a
special Is method. Use the rdf:langString generated proeprties.
- Keep the Set/Get special language members for handling individual
languages.
- Fix bug where non-inherited properties didn't apply to a type, only
the type's children.
- Added orderedItems.
- Excluded items property from OrderedCollectionPage.
- Fixed OrderedCollectionPage extending from two types.
All tests pass. However:
- Need to inject the type property constructor at init time, much like
the manager. Statically linking sucks and really slowed it down with
the direct linking method currently being used. I suspect this makes
it no longer compile on a Raspberry Pi 3, so even more of a reason to
do it at init time.
- Having the type property automatically set at construction time is an
extremely nice feature lacking in v0.
- Unfortunately, right now this introduces a hack in the convert
package.
- Modified the 'type' property definition to also be a string for major
convenience; it has no semantic significance as xsd:string.
- Add missing ActivityPub actor and object properties
- Introspect type when deserializing
- Unknown on properties is now an interface
- Can now generate code when an extends hierarchy is specified multiple
times as a range.
守矢諏訪子
Gabe Kangas