Re: Regular SWICG meetings and CG process

čt 30. 3. 2023 v 22:34 odesílatel nightpool <eg1290@gmail.com> napsal:

> Kevin is correct, but the core specs have *extensibility* based on JSON-LD
> namespacing, and a few non-obvious features (like the majority of
> properties being "non functional" (they accept arrays as easily as single
> values) that can trip up consumers used to more statically types languages
> with strictly defined schemas (Which, in fairness, JSON famously is not)
>
> The specs are based on a common subset of JSON that's accessible to both
> pure JSON consumers and JSON-LD consumers, which means that developers used
> to either will need to make a few compromises with their implementations,
> but in return we're able to bridge the gap between these worlds more
> effectively then if we required all developers to use one or the other.
>

Yes, indeed.  As I think I mentioned this came up at the Paris F2F, which I
dont recall Kevin was at.  How to extend things, and the fact that JSON-LD
having an existing extensibility mechanism was a plus.

That said, I think the manner in which JSON and JSON-LD work together has
room for improvement.  JSON-LD tooling often struggles to parse JSON, and
it need not.  The workarounds of using @json and @vocab are not ideal, in
fact the definition of @vocab has changed over the years.

We've seen in groups such as VCWG new things being tried such as a default
@vocab for unregistered terms and mime type hacks.  Again none of this is
ideal.

But it could be a topic for discussion going forward.  It might be fair to
say we all have the same goal of allowing JSON and JSON-LD to live side by
side, and giving developers a choice, a good devX and allowing the system
to scale.  (Easier said than done!)


>
> On Thu, Mar 30, 2023, 3:17 PM Kevin Marks <kevinmarks@gmail.com> wrote:
>
>>
>>
>> On Thu, 30 Mar 2023, 10:23 Bumblefudge von CASA, <
>> virtualofficehours@gmail.com> wrote:
>>
>>> On 3/30/2023 4:10 AM, Aaron Gray wrote:
>>>
>>>
>>>>
>>> 1.5. JSON-LD @context extension declarations and comprehension
>>>
>>>     https://json-ld.org/
>>>
>>> Yes, the core specs are LD-based and without a little tooling and
>>> harness work, it can be very hard to have interop deeper than the API
>>> layer.  Hearing that Evan has pieces of and can revive a self-service
>>> validator for AS2 objects is great news, this feels like step 0 to me.  The
>>> LD wizards and the catherders need to work together on making this kind of
>>> stuff more accessible and self-service, so that newcomer implementers
>>> without an LD background don't smash their head against it and develop a
>>> deep, debatably justified grudge at that layer.
>>>
>>
>> This is being repeated, and it is a mistake.
>> The core specs are not LD-based. They are JSON based, but included the
>> @context as a courtesy to those who like using LD tooling.
>>
>> You do not need to use LD to interoperate with ActivityPub or
>> ActivityStreams, and if you do use LD you need to be careful to make the
>> output compatible with the JSON form again afterwards if you expect to feed
>> it back into AP or AS tools.
>>
>>