EPR`s, RefP`s, and MSDN2

Tim Ewald`s recent MSDN article on the details of the new MSDN2 URL scheme is really quite fascinating. The implementation details are pretty cool, but what really grabbed my brain was his discussion of identifiers at the top of the article. At least in my head, it related nicely to the recent discussion of ReferenceProperties and identifiers in the context of WS-Addressing. One of the things that has bugged me about the discussions of RefP`s has been a lack of a proper motivating example -- the canonical use cases of message correlation and transaction ID`s have been beaten into the ground, and people have been reaching really hard to find other examples where RefP`s would play a useful role.

In his article, Tim describes some of the characteristics of the new URL scheme. The most important step forward was that MSDN2 now assigns every unique help topic its own GUID identifier. In W3C terms, MSDN2 treats an abstract help topic -- not a particular document representation of that topic -- as the "thing being identified" by the URL. Asking for a document by its GUID returns a document containing the current version of that topic displayed in your current locale. Wait around for another release, or move your computer to France, and the same URL might return a different representation of the same resource. In fact, a particular resource can have many different representations -- the exact representation you get back is at least a function of the version and locale you specify (there are possibly other axes as well here, like VB.NET or C#). You can specify as many or as few additional URL parameters as you want, and the concrete representation of the resource you get back depends on what you asked for in the URL.

Here are a few of the URL`s Tim uses for illustration:
http://msdn2.microsoft.com/library/b8a5e1s5 (Current version in current locale)
http://msdn2.microsoft.com/library/b8a5e1s5(vs.8) (VS.8 version in current locale)
http://msdn2.microsoft.com/library/b8a5e1s5(fr-FR) (Current version in French)
http://msdn2.microsoft.com/library/b8a5e1s5(vs.8, fr-FR) (VS.8 in French)

It`s interesting that they chose to munge parameters at the end of the URL. The composability and optionality requirements don`t map nicely to a hierarchical organization, but I`m curious what motivated them to shy away from query strings. I wonder if that wasn`t just strictly for aesthetic purposes, but I think there are deeper issues related to identity embedded in that decision. Putting these additional parameters into the URL instead of the query string allows the parameterized URL to act as an identifier for a specific representation of a resource -- in short, adding parameters to the URL implicitly changes the "thing being identified" from help topic to specific representation of help topic. The parameters are not components of the help topic`s identity, but they are critically important in specifying the identity of the related resource.

This relationship is worth exploring.

On one hand, we have an idea of an abstract resource called help topic. This resource is uniquely identifiable and addressable, so it meets the W3C Web Architecture definition of "resource". However, the help topic resource has several different representations, each of which are themselves uniquely identifiable and addressable. So are the versioned, locale-specific representations of a particular help topic themselves resources I think the relationship between a versioned, locale-specific help document and its associated help topic is what Dave Orchard was referring to by the term "secondary resource" when he was talking about in his EPR`s and FragId`s article a year ago.

Here`s one way a help topic resource might be addressed via WS-Addressing:

   http://msdn2.microsoft.com/library/b8a5e1s5


And here`s how a versioned, localized help document representation of that topic might be addressed:


   http://msdn2.microsoft.com/library/b8a5e1s5
  
        VS.8
        fr-FR
  


Coupled with something to convey a GET semantic (either a SOAP action or an HTTP protocol verb), this seems like a pretty good way to get help information from a hypothetical MSDN web service. So, a question: do these EPR`s refer to the same thing

If by "thing" you mean help topic, the answer`s yes. However, if you want to get snitty about it, the answer`s really no. The first EPR refers to an abstract resource whose representation may change over time. The second EPR refers to a static unchanging representation of said resource. Semantically, I think they refer to two distinctly different (but related) things. I think this is a good example of how the identifying nature of ReferenceProperties could have been used in a real-world scenarion. However, with the recent banishment of ReferenceProperties in favor of ReferenceParameters (which do not have identifier semantics), the two EPR`s shown above definitionally refer to the same `thing` according to a strict reading of the WS-Addressing specification.

Maybe the "thing" in question is neither a help topic or a help document. Maybe the "thing" is the SOAP node listening for "send me help information" messages. If that`s the case, then the topic id is misplaced -- it should be moved out of the To and into the RefP`s like so:

   http://msdn2.microsoft.com/library/
  
        b8a5e1s5
        VS.8
        fr-FR
  

 

When we do that, we`re much closer to something that identifies a literal SOAP endpoint, but are even further abstracted away from being able to uniquely identify the results obtained from such a request. Blah. What good are they, then If I can`t use the RefP`s to identify the results, what`s so special about that information that it has to go in the addressing headers If that`s the case, I think I like what happens when you put that stuff in the body:

 
     http://msdn2.microsoft.com/library/
     http://schemas.xmlsoap.org/ws/2004/09/transfer/Get
 
 
    b8a5e1sa
    VS.8
    fr-FR
 


That seems relatively straightforward. Presumably (if such a service were to exist), I could send it this message and get back the French translation of the VS.8 docs from now till the end of time. So, how do I refer to the French translation of the VS.8 docs later, since the secondary resource now lacks an identifier Is the whole SOAP envelope now an identifier

I guess I`m feeling a little nostalgic for ReferenceProperties. My ideal world would have ReferenceProperties back in the spec (in all their identifying glory), with ReferenceParameters banished into the body of the message (since they`re not part of any logical identifier, they don`t belong in the addressing headers). I`ve never understood the motivation for ReferenceParameters and have had an innate distaste for them since I first encountered them, but I guess I`ll just have to live with it.