Re: proposed resolution to issue #30

Jacek,

I agree that next and none wouldn't be dereferencable,
but that doesn't preclude use of relative URI actor
values that are relative to the base URI...

Cheers,

Chris

Jacek Kopecky wrote:

>  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:46:21 UTC