Re: proposed resolution to issue #30

 Huh, well, Chris, as I see it, nothing in the text suggests that
the URI can be referenced and what should be found there, and the
text gives two concrete URIs, .../next and .../none, that I can't
even imagine why anybody would want to dereference them.
 Certainly, an extension could use actor URIs for example for
targetting, but then this would be well specified in the
extension. IMHO SOAP itself defines actors as "not to be
dereferenced".
 I see namespace URIs, encodingStyle URIs and actor URIs as
modeled exactly in the same way - as identifiers that "should
have the characteristics of uniqueness and persistence" (from
[1]). Nothing more. 8-)

                            Jacek Kopecky

                            Idoox
                            http://www.idoox.com/



On Wed, 24 Oct 2001, Christopher Ferris wrote:

 > Jacek,
 >
 > I disagree that the URI value of an actor attribute
 > cannot be dereferenced. Nothing in the text suggests
 > that it can't be used in this matter.
 >
 > Cheers,
 >
 > Chris
 >
 > Jacek Kopecky wrote:
 >
 > >  Noah,
 > >  I agree that as SOAP is an XML format it has URIs all over it.
 > > But the only ones that something can reasonably attempt to
 > > resolve are the hrefs and other application-dependent URIs.
 > >  Namespace URIs are not to be resolved by definition [1].
 > >  Actor URIs are not to be resolved by definition [2].
 > >  EncodingStyle URIs are not to be resolved by definition [3].
 > >  The only URIs that are designed to be resolved are hrefs and
 > > maybe some application-defined ones. Well, we cannot rule the
 > > latter. Hrefs are a matter of the Encoding and I don't see a
 > > reason for moving it to the core.
 > >
 > >  An href URI can or cannot be referenced when it's needed.
 > >  I think the options we to solve this situation have are:
 > >  1) SOAP Encoding does not guarantee href URIs to be
 > > dereferencable unless they are of the form "#<id>". A transport
 > > binding, an extension or an application MAY add other guarantees.
 > >  2) SOAP Encoding href URIs are always dereferencable, it is the
 > > responsibility of the sender to make sure the URIs will be
 > > dereferencable, possibly by means of a transport binding, an
 > > extension or the application. In case of a failure when
 > > dereferencing an href URI the processor will generate a
 > > SOAP-ENC:UnreachableReference fault. (We might want to specify how
 > > to add the URI that was unreachable to the detail in the generated
 > > Fault.)
 > >
 > >  I don't have preference towards any of the presented two
 > > options.
 > >
 > >  If I forgot about some URIs that can be present in the message,
 > > please mention them. 8-)
 > >
 > >                             Jacek Kopecky
 > >
 > >                             Idoox
 > >                             http://www.idoox.com/
 > >
 > > [1] http://www.w3.org/TR/REC-xml-names/#dt-NSName
 > > [2] http://www.w3.org/TR/2001/WD-soap12-part1-20011002/#soapactor
 > > [3] http://www.w3.org/TR/2001/WD-soap12-part1-20011002/#soapencattr
 > >
 > >
 > > On Wed, 24 Oct 2001 Noah_Mendelsohn@lotus.com wrote:
 > >
 > >  > Jacek Kopecky writes:
 > >  >
 > >  > >> AFAIK, SOAP+attachments uses this Encoding mechanism
 > >  > and
 > >  > >> The core SOAP does not have any referencing
 > >  > >> mechanism for it doesn't need one. It's the
 > >  > >> data that may need references, thus
 > >  > >>it's the encodings that may want to specify
 > >  > >> referencing.
 > >  >
 > >  > I see it a bit differently.  S+A and Dime are meant to work with unencoded
 > >  > body and header entries as well as encoded ones.  The very fact that we
 > >  > are "Web" services and using XML formats implies that message content can
 > >  > include URIs, regardless of how they are represented lexically, what
 > >  > encoding is used, whether they are set off separately in attributes or
 > >  > elements or in running text content, etc.
 > >  >
 > >  > In all these cases, the question arises:  "are there any rules about which
 > >  > URI's will successfully resolve at any given node and at any given point
 > >  > in time."  For SOAP in general, the answer must be "no", except insofar as
 > >  > we establish URI's for the envelope itself.  If I put the URI
 > >  > http://www.ibm.com/noahsxray.jpg into a SOAP message, there should be no
 > >  > conformance requirement on SOAP processors that anything be available at
 > >  > that URI.
 > >  >
 > >  > By contrast, if I'm using SOAP + Attachements,  and if I use a content ID
 > >  > that in fact is properly declared in the MIME envelope, then indeed the
 > >  > reference MUST resolve.  This is true regardless of whether I am using
 > >  > encodings or not.  In fact, it's true regardless of whether the URI
 > >  > reference appears explicitly in the envelope or is just implied by its
 > >  > contents.
 > >  >
 > >  > I am recommending that we make clear that core SOAP has no such
 > >  > conformance requirement, but that features such as S+A or DIME can indeed
 > >  > indicate URI's which MUST successfully resolve.  I have recommended that
 > >  > we open an issue to consider this question.  Thank you.
 > >  >
 > >  > [1] http://www.w3.org/TR/SOAP-attachments#SOAPReferenceToAttachements
 > >  >
 > >  > ------------------------------------------------------------------------
 > >  > Noah Mendelsohn                                    Voice: 1-617-693-4036
 > >  > Lotus Development Corp.                            Fax: 1-617-693-8676
 > >  > One Rogers Street
 > >  > Cambridge, MA 02142
 > >  > ------------------------------------------------------------------------
 > >  >
 > >  >
 > >  >
 > >
 >
 >

Received on Wednesday, 24 October 2001 13:42:29 UTC