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

John, I agree-the WS-Addressing spec is not very clear.  I'm going on
the basis of what I understand the spec to be saying based on outside
discussions and criticisms of what specs have been doing with EPRs.

 

Philippe, desperately need your help here to clarify EPR issues.

 

Kirk Wilson, Ph.D.
Research Staff Member

CA Labs

603 823-7146

 

________________________________

From: public-sml-request@w3.org [mailto:public-sml-request@w3.org] On
Behalf Of John Arwe
Sent: Thursday, September 13, 2007 8:24 AM
To: public-sml@w3.org
Subject: [w3c sml] [4637] Construction of EPR Reference Scheme

 


I think it's time to clarify a few things here now that I am getting dug
out enough to catch up with this thread.  I will try to set a good
example by providing citations for my (and in some cases others')
assertions. 

> 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. 

I don't think it was rejected. There was enough consensus among the
submitting companies to include it in the submission [SMLSubmit].  At
the [JuneF2FMinutes] the fact that the examples in the submission copy
conflicted with the web architecture document  by using WS-Addressing
Reference Parameters (which WS-Addressing explicitly discusses
[WSA-WebArchURIs],[AoWWW-URIBenefits]) was pointed out by one of our W3C
Team Contact members [JuneF2FMinutesEPREx], and a suggestion for
changing the examples was made to align them properly with the cited
documents.  I'm not sure how fixing examples equates to rejecting the
entire scheme.  Separate questions were raised at the same meeting as to
whether or not the working group wanted to retain the EPR scheme in the
spec, yes.   

> the resource identification information must be contained in the URL
that is the value of the <wsa:Address> element 

I see where some of the WS-A controversy comes from after re-reading it,
there are statements that I can tilt my head to read as internally
consistent or not.  E.g. 

1. "A Web service endpoint is a (referenceable) entity, processor, or
resource to which Web service messages can be addressed. Endpoint
references convey the information needed to address a Web service
endpoint. " [WSAIntro] 

2. "[address] : IRI (1..1)     An absolute IRI [IETF RFC 3987]
representing the address of the endpoint. " [WSAInfoModel] 

3. "[destination]: this property takes the value of the EPR's [address]
property."  [WSASend] ok, so the IRI above has the properties of a
location too [RFC3986URI section 1.1.3] 

4.  "A reference may contain a number of individual parameters that are
associated with the endpoint to facilitate a particular interaction.
Reference parameters are namespace-qualified element information items
that are required to properly interact with the endpoint. Reference
parameters are provided by the issuer of the endpoint reference and are
assumed to be opaque to other users of an endpoint reference."
[WSAInfoModel] 

5. "Using abstract properties of an EPR other than [destination] to
identify resources is contrary to this recommendation."
[WSA-WebArchURIs] 

For me at least, 5 is overly broad.  I suspect the authors meant to say
something more refined, that the ref parms should not be used to
identify the resource to interact with.  My narrower version would
permit a URI/IRI to a policy governing the exchange, which seems
perfectly within the intent of #4 and within the intent of every
discussion I have heard on this subject, including from first-hand
participants in the working group.  Kirk, weren't you one of the WS-A wg
members?  Perhaps you could speak to your understanding of the
discussions and correct me if I have heard wrong. 

> 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 

Syntactically they are allowed from what I see in [WSAInfoModel] and
[RFC3987IRI 2.2] ("IRI = scheme ":" ihier-part [ "?" iquery ] [ "#"
ifragment ]"), so I assume your assertion is semantically motivated. 

[RFC3987IRI 5.3.3]  has a bit on fragments "The fragment component is
not subject to any scheme-based normalization; thus, two IRIs that
differ only by the suffix "#" are considered different regardless of the
scheme."  The rest of the discussion of fragments seems to happen in
[RFC3986URI], eg. section 3.5 (the "linguistic rathole").  As I read
that section, it treats client-side fragment handling as a feature (i.e.
intentional and desirable) so I'm unable to match it to your assertion
above.  Did you have a specific implementation in mind perhaps, whose
structure might be true and one choice amongst >1 ?  It also seems to be
tailor-written for our general XML document case, but I am willing to be
educated.  Could you precisely point out the semantic problem and cite
reference(s)? 

> could the query component of the URI be used? 

This is exactly what I remember being suggested at the June F2F,
although I see no indication of that in the minutes.  [RFC3986URI],
section 3.4 is the heart of the query description.  It says the query
component contains non-hierarchical data, but I am unclear what the
definition of that is.  Certain xpath 1.0 expressions I would be easily
convinced are hierarchical-looking (*/foo), but others are less clearly
hierarchical to me (/*[@id="bar"]).  The latter has hierarchical
components, but that seems subtly different than saying it is
hierarchical itself.  I could probably express the full semantics of
xpath 1.0 in key=value pairs, i.e. in classic query content syntax, but
it would still express "hierarchical intent"...is that hierarchical
data?  I'm not sure, but absent any contrary citations it sure seems
like I have sufficient degrees of freedom to be within the letter of
this "law". 

> 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.


> This exchange cannot be accomplished simply through the EPR 

You cited one use case that doesn't work in all scenarios, because
additional information is required.  We could discuss the same question
with respect to URIs (go ahead, instigate :-) and you might be surprised
at the answers depending upon how many RFCs you have read starting at
3986.  I read a couple as part of researching this, and they convinced
me our current sml:uri definition is far from enough to guarantee
interop. 

> 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 

You need to answer the same questions for a URI.  3896 does not
guarantee you have those answers, or that the answers are sufficient to
meet SML's requirements.  So if I apply your arguments consistently, and
accept the implicit assumption that a reference scheme definition must
specify all these things, then we should delete the URI reference scheme
as well.  Note: I am not suggesting we kill off URI; I am suggesting
that we have to choose our rules and apply them consistently.  Specs
sometimes choose to leave things unspecified to allow other specs to
build on them (sometimes they are unintentional omissions too); we are
doing the former in SML in several ways, e.g. by drawing a distinction
between model def documents and model instance documents but then
leaving undefined any way to syntactically differentiate between them.
SMLIF needs such a syntax, so we defined it there.  WS-A left a whole
bunch of things unspecified, as does XML Schema (as we have discussed
around how a schema processor locates schema components).  Applying the
same incompleteness arguments to them, they are so incomplete as to be
not worth documenting yet clearly some set of people and W3C members
disagreed with that assessment.  We have the option of making a similar
choice in every feature we spec out. 

> Whether support for an EPR scheme is "required" in SML 

SML (and SMLIF) does not and never did require any producer or consumer
to support the EPR reference scheme.  Feel free to provide a citation
indicating otherwise, as that would be a bug to be fixed.  The intent of
the submitting group was to define the EPR reference scheme in SML, as
the URI ref scheme is defined and not required in SML, to provide a
common definition that can be re-used in dependent specs (eg when SMLIF
requires sml:uri support as an interop floor). 

> I'm wondering what is the use-case behind the creation of a document
reference scheme using EPRs 

Valentina did bring a use case forward to the group for discussion (two,
in fact [VPEPRUsecases]). Historically, we have added features to SML
based on at least one use case.  Valentina provided that for EPRs
recently, and prior to submission since they are in [SMLSubmit];
certainly it is valid feedback to the implementors that they someone
thinks they may be running afoul of the proscriptions in
[WSA-WebArchURIs]. The fact that it did not resonate with the group does
not invalidate the use case however.  It sounds as if we are raising the
bar to require multiple use cases for features to control scope.  Doing
so would require a charter change for the group, and consistent
application of that rule to other existing features of the spec. 


Best Regards, John

Street address: 2455 South Road, Poughkeepsie, NY USA 12601
Voice: 1+845-435-9470      Fax: 1+845-432-9787 

[SMLSubmit] http://www.w3.org/Submission/2007/SUBM-sml-20070321/ 

[JuneF2FMinutes]
http://lists.w3.org/Archives/Public/public-sml/2007Jun/att-0099/20070612
-sml-minutes.html 

[JuneF2FMinutesEPREx]
http://lists.w3.org/Archives/Public/public-sml/2007Jun/att-0099/20070612
-sml-minutes.html#item04 

[WSA-WebArchURIs]
http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/#resourceidentificat
ion 

[AoWWW-URIBenefits]
http://www.w3.org/TR/2004/REC-webarch-20041215/#uri-benefits 

[WSAIntro] http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/#tocRange


[WSAInfoModel]
http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/#eprinfomodel 

[WSASend]
http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/#sendmsgepr 

[AoWWW-URIRef] http://www.w3.org/TR/2004/REC-webarch-20041215/#URI
refers to 2396 not 3896 but... 

[RFC2396Obsolete] http://www.rfc-editor.org/cgi-bin/rfcsearch.pl  shows
that 3896 obsoletes 2396 

[RFC3986URI] ftp://ftp.rfc-editor.org/in-notes/std/std66.txt   

[RFC3987IRI] http://www.ietf.org/rfc/rfc3987.txt 

[VPEPRUsecases]
http://lists.w3.org/Archives/Public/public-sml/2007Sep/0078.html