Still guessing. Please don't assume I know what I'm talking about. My first thought was also what application would satisfy Safari.
Surely possible if you suspect a hash generated on the fly, but based on the URI files I read, the standard tries to encourage permananet ID's like a serial number, attached permanently to everything worth pointing to so that the structure of storage may change but the ID remains. I imagine something like moving your favorite comics from Mom's garage to a storage unit; still Fab4 Volume/Issue URI but the location changed like a path to a file might. Maybe this involves slick search and indexing in the background so there's no work involved editing the script that publishes the link, but I'm really reaching on implementation.
On the client side though, like a mail link being programmatically directed to your own client mail tool, I doubt that any x-webdoc link would have a client-side knowledge and expect an application/handler outside the browser. Inside the browser maybe, but Safari thinks it needs a handler?
The payload, if done client side, would be fairly exotic, like the service that created the link expecting a client side ID to be available, replicated exactly as expected by the service. I can only imagine something like a web-served link expecting to identify an item on a corporate CD inserted in an available client drive, which would lead to a lot of expectations and problems. If you can recall Macromedia CD's in their heyday, catalogues and demo's and such with lots of potential but lots of fail in practice, I suspect why you don't see that kind of design very often. More likely a link generated at the service pointing to something on the same data store behind the service.
My guess includes x-webdoc was never intended for a client application as it was formatted. The links that I just met, which is why I jumped in, were inside an automated email, where many other links in the email worked fine (http, products, etc.) and looked like normal web service links, but the two in question failed and looked like the x-webdoc. They were a "Help" and "Contact" link down at the bottom. I also puttered around with those payloads at the web server address but got nowhere. I believe because the payload only exists inside a back-end database that knows the cross-references and URI, not in any addresses/links/web pages "served" by the web server.
I believe the URI was likely generated by a server-side script, PHP or the like, so that's where to look for an error in the generating of the link, not the ID. In my case, I would guess that the "x-webdoc" are default or stand-in for a link that was supposed to be context sensitive, but the generating script couldn't interpret forming it so the default was slotted in. Output error better than crashing the script, I would also guess,
Happy New Year! Here's to guessing!
