solid-rest icon indicating copy to clipboard operation
solid-rest copied to clipboard

Some remaining differences between NSS and solid-rest

Open bourgeoa opened this issue 4 years ago • 3 comments

@jeff-zucker Apart from resourceMapper, here are the points I can raise for compatibility between NSS and solid-rest : (I have no understanding of Link HEADER or OPTIONS)

  • slug
    • without extension add ext to slug : slug = slug + ext (Tim's recommendation for all resources, can be forced for POST)
    • 400 slug MUST not contain / or | ( slug.match(//|||:/) ) (I seem to remember that it is for mashlib)
  • .acl or .meta ext MUST have text/turtle contentType : 415 required (spec says RDF but it has been agreed text/turtle for NSS)
  • when creating Container create default META (everything works without it)
  • container content displayed as turtle doc contains .meta
  • content Type default to application/octet-stream and not text/turtle (since NSS v5.xx and default mime-type)
  • forbidden to delete root acl, root meta (NSS POD broken)
  • /profile/card contentType is text/turtle and file is card$.ttl ( the last point I suppose can be left to resourceMapper)
  • Resource name must be unique (Container without / at end and Resource) (not in NSS actually)

bourgeoa avatar Aug 07 '20 09:08 bourgeoa

Thanks much, this is a great list.

  • slug without extension add ext to slug : slug = slug + ext

This is for POST only, and Resource only, correct? I can still PUT a resource without extension or POST a container without one?

  • 400 slug MUST not contain / or | ( slug.match(//|||:/) )

We already disallow / and test for the 400 in the tests. I'll add |.

  • .acl or .meta ext MUST have text/turtle contentType : 415 required

Presumably all aux files? And we should require the user to supply this rather than supply it ourselves automatically?

  • when creating Container create default META

A zero-byte file, correct? And we need to 1) create Container 2) read created Container's link header 3) use that address to create the .meta.

  • container content displayed as turtle doc contains .meta

I presume this is in the new aux spec? I've never seen it explicitly stated anywhere. Nice feature though.

  • content Type default to application/octet-stream and not text/turtle (since NSS v5.xx and default mime-type)

When would this apply? My understanding is that both PUT and POST require a contentType, so they should error if there is none specified. And the extension is irrelevant to this question, right? Once the resource-mapper is implemented, the specified contentType will be used regardless if it matches the extension?

Also, this is an NSS thing, not in the spec?

  • forbidden to delete root acl, root meta (NSS POD broken)

Yes, we should disallow that..

  • Resource name must be unique (Container without / at end and Resource)

I guess this means that the solid-rest equivalent of itemExists() should always check both with and without a trailing slash?

jeff-zucker avatar Aug 07 '20 16:08 jeff-zucker

  • slug without extension add ext to slug : slug = slug + ext

This is for POST only, and Resource only, correct? I can still PUT a resource without extension or POST a container without one?

yes

  • 400 slug MUST not contain / or | ( slug.match(//|||:/) )

We already disallow / and test for the 400 in the tests. I'll add |.

yes. (even if I don't understand the rationale)

  • .acl or .meta ext MUST have text/turtle contentType : 415 required

Presumably all aux files? And we should require the user to supply this rather than supply it ourselves automatically?

Presumably yes. In fact there as been a discussion, the result being it MUST be RDF and that for parsing reason in NSS it can only be text/turtle. The check is needed, and yes the contenType is provided by the user

  • when creating Container create default META

A zero-byte file, correct? And we need to 1) create Container 2) read created Container's link header 3) use that address to create the .meta.

yes. zero-byte file. In solid-rest I was with the impression that you choose a simplification and that you don't need to read Container's link header. NSS do not read it allready knows where to store it. This is the choice I also made for _getLinks() in solid-rest. If you think an other route is needed, I suppose you will have the header to depend for some properties on storage()

  • container content displayed as turtle doc contains .meta

I presume this is in the new aux spec? I've never seen it explicitly stated anywhere. Nice feature though.

I shall check the spec. I remember seeing it in the spec discussions

  • content Type default to application/octet-stream and not text/turtle (since NSS v5.xx and default mime-type)

When would this apply? My understanding is that both PUT and POST require a contentType, so they should error if there is none specified. And the extension is irrelevant to this question, right? Once the resource-mapper is implemented, the specified contentType will be used regardless if it matches the extension?

Also, this is an NSS thing, not in the spec?

I shall recheck to see if I can find more details. What I am sure about is that :
-- a file without extension should default to application/octet-stream -- an unknown contentType provided by the user defaults also to application/octet-stream It is not in the solid spec but I think it is in other general spec

  • forbidden to delete root acl, root meta (NSS POD broken)

Yes, we should disallow that..

Not sure it is allready in the NSS code but I think is has been added in mashlib

  • Resource name must be unique (Container without / at end and Resource)

I guess this means that the solid-rest equivalent of itemExists() should always check both with and without a trailing slash?

Not implemented in NSS but a recurrent low level demand from Tim.

As you can see I was not precise enough. There is some uncertainty in some cases where the distinction : is it a NSS issue or mashlib one is not understand by me.

bourgeoa avatar Aug 07 '20 20:08 bourgeoa

Thanks, your explanation is very helpful.

jeff-zucker avatar Aug 07 '20 21:08 jeff-zucker