[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/#resourceidentification

[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