@silverpill @steve @raucao is is https://www.w3.org/ns/activitystreams#Note>, but only "Note" is consistent with compacted JSON-LD.
-
@silverpill @steve @raucao <Note> is <as:Note> is <https://www.w3.org/ns/activitystreams#Note>, but only "Note" is consistent with compacted JSON-LD.
Fundamentally, identifiers are expressed in different ways depending on context. The prefix mechanism produces compact URIs, which are still intrinsically URIs despite their lexical form not being a valid URI. If you care about referents, you need to expand them.
"as:Public" is canonical for object properties (type:id). Disliking this fact doesn't make it untrue.
-
@silverpill @steve @raucao <Note> is <as:Note> is <https://www.w3.org/ns/activitystreams#Note>, but only "Note" is consistent with compacted JSON-LD.
Fundamentally, identifiers are expressed in different ways depending on context. The prefix mechanism produces compact URIs, which are still intrinsically URIs despite their lexical form not being a valid URI. If you care about referents, you need to expand them.
"as:Public" is canonical for object properties (type:id). Disliking this fact doesn't make it untrue.
@silverpill @steve @raucao The only thing I can really suggest is dropping the use of the prefix mechanism by undefining the `as` term, then rewriting all other term definitions to not use the `as:` prefix. This might make sense since the media type nominally guarantees the meaning of certain terms, and you really shouldn't define your own custom terms in the `as:` namespace, so maybe it's okay to say that no one should ever use `as:`. Is that the resolution you'd prefer?
-
@silverpill @steve @raucao The only thing I can really suggest is dropping the use of the prefix mechanism by undefining the `as` term, then rewriting all other term definitions to not use the `as:` prefix. This might make sense since the media type nominally guarantees the meaning of certain terms, and you really shouldn't define your own custom terms in the `as:` namespace, so maybe it's okay to say that no one should ever use `as:`. Is that the resolution you'd prefer?
@trwnh @steve @raucao I am not convinced that there is a problem in the first place.
ActivityPub says the identifier is
https://www.w3.org/ns/activitystreams#Public. JSON publishers use full URI. Server implementations that perform JSON-LD processing (e.g. Iceshrimp) also produce full URI, they figured it out. Then, why make a change?If this issue is purely theoretical, then it must be addressed without changing ActivityPub.
-
@trwnh @steve @raucao I am not convinced that there is a problem in the first place.
ActivityPub says the identifier is
https://www.w3.org/ns/activitystreams#Public. JSON publishers use full URI. Server implementations that perform JSON-LD processing (e.g. Iceshrimp) also produce full URI, they figured it out. Then, why make a change?If this issue is purely theoretical, then it must be addressed without changing ActivityPub.
@silverpill @trwnh @raucao These kinds of discussions fascinate me. "Yeah, it's not right, but what's the problem?"
It reminds me of ... -
@silverpill @trwnh @raucao These kinds of discussions fascinate me. "Yeah, it's not right, but what's the problem?"
It reminds me of ... Iceshrimp has hacky workarounds for interop reasons with plain JSON consumers who fail to understand the currently canonical fully conformant normal form of "as:Public" and only understand the non-canonical full URI. Hacky workarounds shouldn't be the norm. If one were to build an AS2 validator right now, the validator would produce documents that cause interop issues. That's the problem we're trying to solve. Issues like this prevent validation from being feasible.
-
Iceshrimp has hacky workarounds for interop reasons with plain JSON consumers who fail to understand the currently canonical fully conformant normal form of "as:Public" and only understand the non-canonical full URI. Hacky workarounds shouldn't be the norm. If one were to build an AS2 validator right now, the validator would produce documents that cause interop issues. That's the problem we're trying to solve. Issues like this prevent validation from being feasible.
@trwnh @steve @raucao If this issue causes an imaginary software to produce invalid documents, then it is not a real issue.
Regarding hacky workarounds: no one is forced to use JSON-LD. The need for a workaround actually suggests that there is a bug in JSON-LD processors, which for some reason mess with property values when they are URIs. That doesn't make any sense.
-
@trwnh @steve @raucao If this issue causes an imaginary software to produce invalid documents, then it is not a real issue.
Regarding hacky workarounds: no one is forced to use JSON-LD. The need for a workaround actually suggests that there is a bug in JSON-LD processors, which for some reason mess with property values when they are URIs. That doesn't make any sense.
@silverpill @steve @raucao That's not what I said at all. The AS2 documents are fully valid, fully conformant, etc. -- there are MUST requirements which describe this, but you seem to be ignoring those MUST requirements while citing a requirement which doesn't exist in AP, based on a misunderstanding of how identifiers work.
Again, you can say "I don't like this", but you can't say "this is wrong". It's evident that fedi impls produce noncompliant AS2, and some fail to consume compliant AS2.
-
@silverpill @steve @raucao That's not what I said at all. The AS2 documents are fully valid, fully conformant, etc. -- there are MUST requirements which describe this, but you seem to be ignoring those MUST requirements while citing a requirement which doesn't exist in AP, based on a misunderstanding of how identifiers work.
Again, you can say "I don't like this", but you can't say "this is wrong". It's evident that fedi impls produce noncompliant AS2, and some fail to consume compliant AS2.
@silverpill @steve @raucao I have already described in the GitHub issue the options available to us. One is to make no normative changes and simply issue updated guidance. The other is to completely rewrite the context document to undefine the "as" term prefix, so that the canonical and conformant form changes from as:Public to the full identifier. (Plain JSON consumers still need to consider JSON-LD when producers augment the context.)
