W3C home > Mailing lists > Public > xml-dist-app@w3.org > December 2001

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

From: David Orchard <dorchard@bea.com>
Date: Mon, 10 Dec 2001 12:48:56 -0800
To: "'Andrew Layman'" <andrewl@microsoft.com>, "'Noah Mendelsohn'" <noah_mendelsohn@us.ibm.com>, "'Jacek Kopecky <jacek'" <jacek@systinet.com>
Cc: "'xml-dist-app'" <xml-dist-app@w3.org>
Message-ID: <00f701c181bc$1684ef10$6c0ba8c0@beasys.com>
I strongly agree with Andrew that processing is application (message
semantics) specific.

We had the same problem in the XML Link working group when dealing with link
bases for simple and extended links, and we came to the same conclusion.
There is no simple mechanism for specifying which links are required to be
de-referenceable (thank god we at least have soap faults not being http 200
return codes), what de-referencable means, what are error conditions from
de-referencing, and whether any such mechanism is normative or simply
"hints" that an application can over-ride.

In the same way the XML Link deferred a processing model for link
resolution - which I believe you need for error handling - XMLP should defer
URI reference processing.  It's just a data-type.

FWIW, the bigger issue becomes: Is a link or reference meta-data,
presentation, hints, required data?  The answer: it depends.  Global
treatment is not possible. The same lessons that XLink learned for hypertext
linking are applicable to general linking semantics expressible in SOAP
syntax.

With XInclude, we took a very narrow processing model view of URI reference
de-referencing because we wanted a very explicit processing model.  This
itself has opened up a huge can of worms on namespace resolution and fixup,
PSVI contributions, id/idref fixup.

Please please let us not deal with this issue.  We will slip our schedule
for little gain.

Cheers,
Dave Orchard
XLink, XInclude co-editor

> -----Original Message-----
> From: xml-dist-app-request@w3.org
> [mailto:xml-dist-app-request@w3.org]On
> Behalf Of Andrew Layman
> Sent: Monday, December 10, 2001 12:00 PM
> To: Noah Mendelsohn; Jacek Kopecky <jacek
> Cc: xml-dist-app
> Subject: RE: issue 168 proposal: xsi:type of external references in
> Encoding
>
>
> Can we make such normative statements universally about URI reference
> processing or should processing depend on the semantics of
> the message?
> I think the latter.
>
> -----Original Message-----
> From: Noah Mendelsohn [mailto:noah_mendelsohn@us.ibm.com]
> Sent: Monday, December 10, 2001 10:06 AM
> To: Jacek Kopecky <jacek
> Cc: xml-dist-app
> Subject: Re: issue 168 proposal: xsi:type of external references in
> Encoding
>
>
> As I've suggested before, I think there are issues relating
> to external
> references that go beyond the encodings, and I think our
> approach has to
> be
> consistent across the cases.  If I send you a document that uses
> encoding
> and has an href to some other URL, what are my obligations in
> following
> that link?  It has very bad performance and security
> implications if you
> even imply that a conforming implementation MUST try to open a random
> URL
> that happens to show up in the href of a document.
>
> This also relates to our handling of SOAP+Attachments and
> DIME, which I
> think we've delayed for now.
>
> So, we need to indicate in the encodings, what is the result
> if there is
> an
> href you choose not to follow or can't follow?  Is it that a fault
> should
> be generated?  Is it the same fault as if an href in the form of a
> fragment
> referencing the envelope itself fails?  Thanks.
>
> --------------------------------------------------------------
> ----------
> 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 15:51:46 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 22:28:13 UTC