Great discussion (“EPR’s, RefP’s, and MSDN2”) from Steve on Reference Properties.
I get the feeling that Steve is forgetting the opaqueness of RefProps and RefParams. It’s not the case that one could just safely put any value in the <version> element and create a new EPR that is useable. The consumer of an EPR should not infer any semantics about what’s in the Reference Properties; only the service knows. The Address + Reference Properties elements of an EPR have to be treated as a pair that doesn’t change and uniquely identifies a resource. That has been the argument of the Web people. Why separate the identity of a resource into two parts (Address and ReferenceProperties)?
I personally prefer to treat an EPR as a reference to a WS and convey any information related to my application logic (e.g. “I want to access the particular version of an MSDN2 page”) in the body of the message. Then, I am talking to a service about a resource and I don’t seem to be talking directly to a resource. This avoids coupling resource identity semantics with the address of a service.
Also, I prefer to name resources with non application/transport-specific URIs. In the MSDN case, a great choice was made to give a GUID to each page created that never changes. A new version just gets another GUID and the page gets related to the previous one through other means. If one wanted, they could establish an ftp connection to msdn and get the “b8a5e1sa” topic.
This is very much according to what I’ve been advocating. So, your last example looks great to me with the caveat that I would have used a URN as an identifier for the resource. LSIDs are a great example of what I am talking about.
I am embarking on a side project that involves memory and multimodal understanding for an…
I was in Toronto, Canada. I'm on the flight back home now. The trip was…
The BBC article "How we fell out of love with voice assistants" by Katherine Latham…
Like so many others out there, I played a bit with ChatGPT. I noticed examples…