Re: WebID and Content Negotiation

Hi all,

> Content-negotiation works with static resources too. 

It can work with static resources, too, but in my experience it's not practical
to enable/configure/deploy. AFAIK Jekyll [1], for example, does not support
conneg and therefore neither does GitHub Pages. IT depts in corporate contexts
are rarely interested in enabling it, at least as far as I've seen.

> The spec just tells us what the mime type by default is, so that
> client writers can have some idea of the minimal requirements they
> need to satisfy for interoperability.

In your opinion should this be a default/MUST or a default/SHOULD?

> But if we want people to be able to join the community easily, we can’t
> just before they even get going ask them to write 20 parsers for the
> same data structure. I think it is obvious how that would put people off.

I agree! I started out in favor of a default/MUST on Turtle (as in the current
spec/draft) for this very reason but I have changed my preference to a 
default/SHOULD on Turtle following Kingsley's and Jonas's arguments. I would
also be ok with no default at all and letting the ecosystem spontaneously
converge one way or another.

> I actually wrote up a little table in August showing how defaults on
> the server translate to requirements on the client:
> 
> https://github.com/w3c/WebID/issues/3#issuecomment-898951657

Thank you for pointing to that.

> I think we should be guided by interoperability needs of applications
> that have real momentum. Otherwise this could well be a ”number of
> angels that can fit on a pinhead” type discussion.

I Agree 100%. Practicality above all.

Ultimately, consuming across multiple formats comes across as being
significantly easier than publishing content across multiple formats.
To me, this indicates that we might need to move complexity towards
clients.

> Can we please not discuss that orthogonal topic in this mailinglist - it 
> is super confusing.

> That allows HTTP protocols not having to define conneg in their specs.
> SPARQL 1.1 Protocol refers to conneg with a one-liner:
> https://www.w3.org/TR/sparql11-protocol/#conneg
> That does not seem to have caused problems like the ones we are discussing
> here?

I don't think we can discuss conneg separately from default serialization
and/or serialization at all, even though I agree on their orthogonality. I have
myself come to the conclusion that conneg should not be mentioned in the spec
but it has taken me hours of thinking about it and discussing about it here; 
I suspect a brief mention of conneg might help, as in the SPARQL spec.

Best regards,
Jacopo.

[1]: https://jekyllrb.com

Received on Friday, 28 January 2022 10:09:38 UTC