Re: WebID default serialization for WebID 2.x

Hi all,

> Are you really sure that you want the *IDENTIFIER* to define the rules 
> of the game - e.g. ensure future compatibility?
> 
> I strongly recommend to place constraints on *extension* specs - e.g. 
> Solid spec might say that it can only ever work with yellow identifiers.

Jonas and Kingsley, I think I understand your point but I struggle to reconcile
it with those scenarios in which updating software might not be as easy as we'd
like it to be.

I appreciate how your approach, by eliminating conneg and MUSTs, would lend
itself to a whole spectrum of WebID publishers, from static resources to
conneg-enabled multi-format WebID servers. However, I can't see an easy way
for WebID clients to keep up. 

For example, let's assume a super-successful WebID 2.0 and let's say I am
working on a device with an embedded WebID client. One of my goals in building
such a device according to a standard such as WebID would be to decouple the
lifetime of the device itself from that of the company that makes it, at least
to the greater possible extent. Hardware should not break and become unusable
when the manifacturer ceases to exist. In this scenario, wouldn't a WebID spec
without a default serialization format enforced via MUST be extremely prone to
shortening the lifespan of the device itself even in a world that fully
embraces WebID?

I do feel that I might be missing something but I don't want to monopolize this
thread. I would be grateful if you could point me to any resources that might
help me understand your approach, also privately. You've probably been making
these points for a long time, particularly to those who prefer a single default
serialization format like I do, and I appreciate the effort in maintaining the
kind and welcoming attitude.

Best regards,
Jacopo.

Received on Tuesday, 25 January 2022 08:36:50 UTC