- From: Karol Szczepański via GitHub <sysbot+gh@w3.org>
- Date: Wed, 17 Jul 2019 19:53:06 +0000
- To: public-hydra-logs@w3.org
> Indeed, but I think we need revolutionary Not really - there are a couple of other specs built on top of hydra that has some more implementations. We shall keep as much of the backward compatibility as possible. I'd still like to downgrade the mentioned rdfs:range from `hydra:Class` to `hydra:Resource` so either `RequestSpecification` or `MediaTypedResource` from #186 (or whatever name would it be) fits by being a `hydra:Resource` > Definitely inspired by the former proposals, but I intend a flexible solutions Well - those approaches also claimed to be flexible. > would the min/max cardinalities cover that? Having multiple 0-1 parts, each for a different class... I meant we need to think it over carefully. There are several places that would benefit from cardinality specifications. There are also other vocabs that already provide these semantics. >Long answer: you'd need to invent/resuse even more terms to describe objects of those properties. >With multipart/form-data we're using same approach everyone else on the web uses. Quite the opposite - `hydra:property` already exists. I'm not claiming that pushing base-64 files through RDF payloads is a nice and clean approach. I'm just saying that handcrafting a sculpture with multipart content that is also not that common (older web API frameworks may not provide support out of the box) is neither a pretty one. > And cannot agree with the serious processing. I remember I tried to send a multipart requests in a browser and it end up with not so nice code. Maybe something has changed since that time, but it is not something a browser can provide out of the box. Maybe there are already some JS libraries to make it easier, but it still requires some heavy stuff written that uses file API, buffers and other quite fresh JS elements available in modern browsers. In general - it feels like 'RequestSpecification'/'supportedContentType' related part is somehow similar to terms presented in #186 and both should meet same criticism and alternate ideas, i.e. @angelo-v 's approach with more generic constraint-like specifications (experiment provided with #187). As for the multipart content - it looks like it was created solely to meet some particular requirement and feels it was not well considered. It seems to be heavily coupled with HTTP and it does not tackle various scenarios (i.e. pre-uploading like in web mail clients where attachments can be uploaded before sending an email). -- GitHub Notification of comment by alien-mcl Please view or discuss this issue at https://github.com/HydraCG/Specifications/issues/199#issuecomment-512543920 using your GitHub account
Received on Wednesday, 17 July 2019 19:53:08 UTC