Hi Guido. I... think you're misunderstanding the goal here. PSR-13 is already approved, and has been for a few years now. It just handles hyperlinks on value objects modeling some REST/HATEOS format. Anything else is out of scope.
The goal here is simply a minor upgrade to the existing standard to leverage the better parameter/return typing support in recent PHP versions. Any other changes are out of scope. Addressing the broader question of REST workflows is definitely not something this addresses, nor should it. -- Larry Garfield la...@garfieldtech.com On Mon, Dec 2, 2019, at 11:29 PM, Guido Faecke wrote: > As PSR-13 is stating, there is no single common hypermedia format. > Instead of trying to improve the existing one, why not create a new one > where we put all the guess-work to rest? > RPC response codes, REST response codes and everything in between has no > real standard. > I struggle every day with making up a "standard" for REST and RPC > between PHP and Java developers. > At that point we need to think about all the other consumers. Maybe I am > way off...anyway, I like the approach and would appreciate any > standardized solution. > > Just adding my 2 cents... > > On 12/2/19 5:13 PM, Larry Garfield wrote: > > Hi folks. > > > > Now that we have a shiny new process for how to adapt older PSRs to modern > > language features, I offer up PSR-13 as a guinea pig while we work through > > any kinks. It's a fairly small and focused PSR so if we screw up something > > along the way the impact is less than if we broke, say, PSR-3 or PSR-7. :-) > > > > The various PRs are here: > > > > Standard: > > https://github.com/php-fig/fig-standards/pull/1199 > > > > "v2": > > https://github.com/php-fig/link/pull/6 > > > > "v3": > > https://github.com/php-fig/link/pull/7 > > > > Feedback welcome, on both details and process. > > > > This will require an Errata vote of the Core Committee in no less than 2 > > weeks. That of course puts us right up against the holiday break, so if > > folks want to hold off on the actual Errata vote until after New Years I'm > > OK with that. I just wanted to get the process kick started. > > > > Related: There's an open PR now against link-util, from me, so I shouldn't > > merge it. I am not sure who else should: > > > > https://github.com/php-fig/link-util/pull/5 > > > > Upon adoption of the new spec versions, I'll handle releasing updated > > versions of the util library. I am not sure if I will bother with a 2 step > > release or just jump straight to the final version, frankly. (Input > > welcome if you have strong feels.) I'll also bump the PHPUnit version at > > the same time (per another PR I recently closed). > > > > -- > You received this message because you are subscribed to the Google > Groups "PHP Framework Interoperability Group" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to php-fig+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/php-fig/6258ac01-9b73-1d10-2057-ba21c76af994%40gmail.com. > -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/6d994e6c-9dd4-4896-90f5-b3a9e74fd822%40www.fastmail.com.
