RE: [w3c sml] [4637] Construction of EPR Reference Scheme

All
We have 19 bugs that are marked as "needs Agreement" for second draft,  and we have 8 working days to finalize the second draft and send it to the W3C webmaster for publishing. We should try to reach consensus on most of these bugs in email before the next week's call.  I will start instigating the drive to consensus for the bugs that have already been discussed in detail in email threads or in Bugzilla comments.

In this specific case, Kirk has clearly elucidated the main issues with EPR scheme, and has proposed that the EPR scheme be removed from the SML spec.

Please speak up now if you disagree with Kirk's proposal - silence will be treated as consent :)

Thanks!
Pratul


From: public-sml-request@w3.org [mailto:public-sml-request@w3.org] On Behalf Of Wilson, Kirk D
Sent: Friday, August 24, 2007 5:58 AM
To: public-sml@w3.org
Subject: [w3c sml] [4637] Construction of EPR Reference Scheme

All,

This email will serve to "instigate" discussion of issue 4637 regarding the EPR Reference Scheme.  See section 3.2.2.  (I fully expect this "instigation" to raise controversies.)

The SML spec attempts to illustrate the creation of another reference scheme (besides the URI scheme) using EPRs.  The initial version of this scheme was rejected because of an unacceptable use of the <wsa:ReferenceParameters> particle in order to contain information identifying the document segment being referenced.  (The "wsa" namespace refers to the namespace of the adopted WS-Addressing recommendation http://www.w3.org/2005/08/addressing.)  While there are defenders of this kind of use of ReferenceParameters (to contain resource identification information), it is strongly rejected by W3C as "inconsistent with the architecture of the Web".  (I have worked and currently am working in several standards groups which have used ReferenceParameters in this manner.  One group just decided to avoid all talk of EPR construction; the other still adopts the identification role of ReferenceParameters as central to its own architecture.)

The issue regarding the use of ReferenceParameters is sometimes misleading represented as an issue over the opacity of ReferenceParameters to client.  Making the issue one of opacity vs. transparency of the ReferenceParameters misses the main issue.  The main issue is, What is the referencing mechanism under the Web?  Where/How should the resource identification information be incorporated into a Web reference?  The architectural requirement of the Web is that all such information be placed in the URL (essentially the <wsa:Address> particle of the EPR), not spread out in other elements of the EPR.  It follows that incorporating the identification information into the EPR cannot be achieved by placing it in a "less" opaque element such as <wsa:Metadata> or even an extension element.

To have an acceptable EPR scheme, therefore, the resource identification information must be contained in the URL that is the value of the <wsa:Address> element.  A case might be made for using EPRs under this condition if the reference is to root element of the document (the URL would essentially be the URL of the document itself).  However, we encounter a problem in the case of referencing a segment, or fragment, of a document.  As I understand it (although I haven't found anything that explicitly says this), the use of fragment identifiers is illegitimate in EPRs because they are handled by the client-servers providing resources do not handle fragment identifiers in the identification of the service being addressed.  On the other hand, could the query component of the URI be used?  This seems dubious to me, since a query must contain non-hierarchical data (which a document fragment certainly is not).  Modifying the URL to reference a document fragment appears to be the only solution to sustaining a robust EPR reference scheme that is consistent with the semantics of EPRs; however neither the query component nor fragment identifiers seems to be a possible course to address achieving this scheme.  (Ok, I'm "instigating" here :).)

Indeed, I'm wondering what is the use-case behind the creation of a document reference scheme using EPRs.  Typically, EPRs are provided by services to clients so that those clients have a means (and possibly other relevant information) to establish an active connection with those services.  I suspect the use-case for the EPR reference scheme involves a SML consumer that is actively going out to an information resource (in real time), which is addressed by the EPR, to obtain some information contained in the document that the information resource makes available.   There are protocols to accomplish this exchange, e.g., WS-ResourceProperties (OASIS), fragment-level "get" in WS-Management (DMTF), and WS-ResourceTransfer (unaligned).  This exchange cannot be accomplished simply through the EPR.  What must the EPR scheme look like to satisfy this use-case?  We would need the EPR in order to address the resource, but we would also need to know the message exchange protocol and the structure of the SOAP Body (or in one case, an element of the SOAP header - !) that specifies the query for the desired fragment of the document.  (The query language can range from referencing a single child of the document root to a full XPath expression depending on the protocol.)

If the conclusions reached here are plausible, then I would suggest that the minimum course is to remove the EPR reference scheme from SML and let it be defined by a separate effort.  (Now I'm trying to be provocative. :).)

Kirk Wilson, Ph.D.
CA Inc.
Research Staff Member, CA Labs
Intellectual Property and Standards
Council of Technical Excellence
W3C Advisory Committee Representative
Tele: + 1 603 823-7146
Fax:   + 1 603 823-7148
<mailto:kirk.wilson@ca.com>