RE: issue 168 proposal: xsi:type of external references in Encoding

I'm confused about what you would like XMLP to do.  I posit that XMLP
cannot/should not define any kind of additional elements/attributes for
purposes of encoding information about references and hints/rules on what to
do with references.

SwA does not indicate how/when to indicate that references are to be
dereferenced.  It talks about URI resolution, not dereferencing.  To me, it
says that a receiver application may choose to follow certain rules for URI
resolution, and it's up to the receiver application to know which references
they should be applied to.  Which I like because it says nothing about
indicating when/which/how dereferencing should occur.

I don't want to go into the "means used to reference" can o' worms.

I will observe that in our implementations of SwA, the questions about
dereferencing - and what that exactly means - have often come up.  Further,
how to reference attached content from an application, stitching together or
leaving separate the multiple infosets, etc. are still application specific
features.

I personally think that the combination of SwA + XInclude would be a
wonderful combination as XInclude does have explicit processing rules on how
to resolve URI-references and what to do with the results.  But that's a
different soap(argh)box and I'm not biased whatsoever.

Cheers,
Dave

> -----Original Message-----
> From: xml-dist-app-request@w3.org
> [mailto:xml-dist-app-request@w3.org]On
> Behalf Of Noah Mendelsohn
> Sent: Monday, December 10, 2001 2:28 PM
> To: dorchard@bea.com
> Cc: andrewl; jacek; xml-dist-app
> Subject: RE: issue 168 proposal: xsi:type of external references in
> Encoding
>
>
>
> SOAP + Attachements provides just the sort of rules I am
> talking about [1].
> Some of the pertinent text is:
>
> "The resolution process for URI references (including
> references used in
> href attributes) in the primary SOAP 1.1 message in a SOAP
> message package
> is based on the rules specified in RFC2557 for multipart MIME
> messages with
> text/html root documents. We adapt these rules from the HTML
> and rendering
> context and apply them to the SOAP 1.1 messaging context. In
> addition, we
> base the relative URI syntax and absolutization rules on
> RFC2396 rather
> than on the now obsolete RFC1808 used in RFC2557."
>
> Why shouldn't we say that transport bindings supporting a
> feature such as
> SOAP + Attachments (or DIME, or whatever) SHOULD provide
> resolution rules
> of this sort, indicating the means used to reference
> information carried
> with the message?
>
> I think this is an important part of the contract when
> sending messages.
> If I send a SOAP message to an occasionally connected device
> (e.g. PDA), I
> know that the entire envelope is accessible when processing
> the message.
> If the transport binding I use gives rules such as above,
> then I similarly
> know that the binary attachment that came with the message is
> accessible,
> and the application sending me the message also knows it will
> be.  Other
> URI's are presumed to be out there somewhere, but when an
> application puts
> one in a message, it has a much lower guarantee of availability to the
> recipient than I would prefer.
>
> [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 Monday, 10 December 2001 21:06:53 UTC