Re: WebID default serialization for WebID 2.x

Quoting Martynas Jusevičius (2022-01-26 14:55:27)
> On Wed, Jan 26, 2022 at 2:41 PM Jonas Smedegaard <jonas@jones.dk> wrote:
> >
> > Quoting Martynas Jusevičius (2022-01-26 13:50:57)
> > > > > This exactly fits my interpretation #2: with an Accept: 
> > > > > text/turtle request header, a WebID profile document MUST 
> > > > > always return Content-Type: text/turtle
> > > >
> > > > So with your interpretation #2, what is served in the *default* 
> > > > situation of *not* explicitly requesting Turtle?
> > >
> > > Normally that should be up to the server. In my logs I sometimes 
> > > see that our clients and servers communicate in formats I didn't 
> > > even know Jena supports, like binary RDF-Thrift.
> >
> > Yes, lots of things are possible, in non-default cases.
> 
> Non-default? That is the default behavior if you let conneg do its job.

> > Conneg is specified only as optional, not mandatory, in core WebID 
> > spec, and consequently for the *default* case (i.e. where only MUSTs 
> > are covered and therefore conneg is totally ignored) any conneg 
> > constraints are totally ignored and specification says Turtle format 
> > MUST be supported so Turtle format will get delivered.
> 
> Again, is this an answer? Are you really saying you're OK to break 
> WebID documents in web browsers by mandating that Turtle (or JSON-LD) 
> is returned no matter what?

No, I am not saying what I think is ok.  I am saying what current draft 
of WebID says it does not specify how to behave in the described case.

The WebID spec only suggests that *if* WebID is used in a context with 
conneg, then certain behaviour probably is good practice.

...which makes sense to me: The WebID spec is about what WebID *is*.

You describe a use of WebID where conneg makes perfect sense, but there 
are other uses of WebID where it does not.  So it makes better sense to 
specify details of your use case in a companion spec tailored your more 
narrow scope.


> Here's my suggestion on how to formulate the constraint: "Provided
> with an Accept request that prefers text/turtle (it is assigned the
> highest q value), the server MUST return text/turtle".
> - servers that only can return Turtle will (ignore the header and) return Turtle
> - servers that support conneg will return Turtle because conneg will do its job
> Is that acceptable?

I would find it confusing and unnecessary to specify that you MAY 
implement conneg which MUST behave a certain way.  Does that mean you 
MUST not implement conneg if done differently, or does it mean that the 
MUST is effectively also a MAY?!?

I would find it acceptable and relevant for a companion spec which 
specifies conneg as at least a SHOULD to then also specify details on 
how conneg SHOULD be resolved.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private