This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Section 4.1 mentions EPRs as a possible value of an SML-IF document reference locator element. Given the hoops that a processor has to go to dereference a document by means of an EPR (e.g., out-of-band information may be required--what interface is supported by the service, what operation to call to access the document) that processor must have to dereference the reference, do we still want to say that a locator can be an EPR? (I would assume so.) If so, we at least recognize that out-of-band knowledge is required (and charactize this this knowledge: e.g., the appropriate wsa:Action or document retrieval operation/parameters. Allowing EPRs as locators, therefore, introduces an extra dimension to the interoperability problem within this area of using document locators.
I'd suggest that we simply state that referencing a document from a locator is, from an implementation standpoint, fundamentally similar to an SML reference. The semantics are different, since locator does not define an arc in the model, but the implementation issues are the same. If we deal with all the issues around this in the EPR Note adequately, there I see no need or advantage to mentioning EPRs specifically here. I will note, again, since people seem to have trouble with the concept, that the number of, size of, and skill required to navigate the "hoops" is a property of the scheme definition, not EPRs. This is every bit as true of URIs - if you disagree, read RFC 3986 again. Saying "it's a URI" does _not_ provide any functional guarantee of interop beyond basics like parsing into components and character escaping. Ditto IRIs.
Resolution is to remove the following sentence: "Typically it is a URI, an XLink [XLink], or a Web Services Addressing endpoint reference [WS-Addressing Core]."
fixed as suggested in comment# 2.