nightpool
commented
7 months ago I don't see any reason why updating the @context should require implementations to support those new terms. They can just ignore unknown terms if they don't care about them.
On Thu, Dec 7, 2023 at 8:19 PM Bumblefudge @.***> wrote:
disclaimer: i have no idea what i'm talking about, so canonical/normative references would be helpful to me and the conversation i'm trying to start.
the extension policy makes it sound like the AS2 @Context file could be updated as often as new extensions were approved by consensus of the CG, with no reference to versioning or min/max frequencies.
if different versions of the AS2 context sat at the same URL, this would mean the referent of the @Context would change often. terms could be mainlined to the as2 context every 2 weeks, which would break RDFC hashes and other graph queries that dereference the @Context values. i don't know how many implementations would be affected by this (the two signing FEPs, ae97 and
`, both seem to use JCS) but i have heard (hearsay, admittedly) that some @Context files in the w3.org/ns namespace are strictly versioned (maybe even according to some version of semver?) to make each update a separate publication. i have no idea how ***@***.***works in SoLiD community, might be worth checking with them?If each context-file update DID create a new version, that would mean implementations have to support those new terms before bumping to the new context URL, right? In semver terms, that sounds to me more like a major version than a minor one (in that even if implementations don't implement those extensions, they at least have to be able to parse them and appropriately ignore those values). This kinda makes an update to the official context sound equivalent to a major or minor version of the spec itself, non?
In summary, I think the flow is right, and this sketches out the lifecycle for optional extensions being described by additional @Context files that could be dropped when their contents get folded it into the next major version... but perhaps those "folding in" events could be bundled together and thought of as AP2.1 or 3.0?
Just spitballing, looking forward to discussing tomorrow!
— Reply to this email directly, view it on GitHub https://github.com/w3c/activitystreams/issues/560, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABZCV3JLGVD6CJPCG3WR43YIJ2J7AVCNFSM6AAAAABAL72BISVHI2DSMVQWIX3LMV43ASLTON2WKOZSGAZTCOBRHEYTMOA . You are receiving this because you are subscribed to this thread.Message ID: @.***>
bumblefudge
evanp
disclaimer: i have no idea what i'm talking about, so canonical/normative references would be helpful to me and the conversation i'm trying to start.
the extension policy makes it sound like the AS2
@Contextfile could be updated as often as new extensions were approved by consensus of the CG, with no reference to versioning or min/max frequencies.if different versions of the AS2 context sat at the same URL, this would mean the referent of the
@Contextwould change often. terms could be mainlined to the as2 context every 2 weeks, which would break RDFC hashes and other graph queries that dereference the@Contextvalues. i don't know how many implementations would be affected by this (the two signing FEPs,ae97and8b32, both seem to use JCS so the contents of the@ContextURL changing wouldn't affect the digest signed) but i have heard (hearsay, admittedly) that some@Contextfiles in the w3.org/ns namespace are strictly versioned (maybe even according to some version of semver?) to make each update a separate publication. i have no idea how@Contextworks in SoLiD community, might be worth checking with them?If each context-file update DID create a new version, that would mean implementations have to support those new terms before bumping to the new context URL, right? In semver terms, that sounds to me more like a major version than a minor one (in that even if implementations don't implement those extensions, they at least have to be able to parse them and appropriately ignore those values). This kinda makes an update to the official context sound equivalent to a major or minor version of the spec itself, non?
In summary, I think the flow is right, and this sketches out the lifecycle for optional extensions being described by additional
@Contextfiles that could be dropped when their contents get folded it into the next major version... but perhaps those "folding in" events could be bundled together and thought of as AP2.1 or 3.0?Just spitballing, looking forward to discussing tomorrow!