Re: proposed resolution to issue #30

 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:06:23 UTC