This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 5383 - Use of EPRs as SML-IF locators
Summary: Use of EPRs as SML-IF locators
Alias: None
Product: SML
Classification: Unclassified
Component: Interchange Format (show other bugs)
Version: unspecified
Hardware: PC Windows XP
: P2 normal
Target Milestone: LC
Assignee: Kumar Pandit
QA Contact: SML Working Group discussion list
Depends on:
Reported: 2008-01-16 18:37 UTC by Kirk Wilson
Modified: 2008-01-18 08:48 UTC (History)
0 users

See Also:


Description Kirk Wilson 2008-01-16 18:37:56 UTC
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.
Comment 1 John Arwe 2008-01-17 13:30:30 UTC
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.
Comment 2 Virginia Smith 2008-01-17 19:30:02 UTC
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]."
Comment 3 Kumar Pandit 2008-01-18 08:48:04 UTC
fixed as suggested in comment# 2.