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

Re: proposed resolution to issue #30

From: Jacek Kopecky <jacek@idoox.com>
Date: Tue, 23 Oct 2001 10:53:39 +0200 (CEST)
To: <Noah_Mendelsohn@lotus.com>
cc: <xml-dist-app@w3.org>
Message-ID: <Pine.LNX.4.33.0110231047430.27743-100000@mail.idoox.com>
 Noah, since id/href is an Encoding mechanism, IMHO it is not
possible to say which URIs are/aren't dereferencable for all
imaginable referencing mechanisms.
 AFAIK, SOAP+attachments uses this Encoding mechanism so it can
state that cid: scheme is dereferencable.
 The Encoding can state that "#<id>" URIs are dereferencable.
 DIME can state whatever applies to it.
 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 don't think we want to create an encoding-independent data
referencing mechanism. 8-)
 Best regards

                            Jacek Kopecky


On Mon, 22 Oct 2001 Noah_Mendelsohn@lotus.com wrote:

 > Sounds good as long as we open the issue...the dereferenceable URI
 > question applies to non-encoding scenarios too (any use of
 > SOAP+attachments or DIME.)
 > ------------------------------------------------------------------------
 > Noah Mendelsohn                                    Voice: 1-617-693-4036
 > Lotus Development Corp.                            Fax: 1-617-693-8676
 > One Rogers Street
 > Cambridge, MA 02142
 > ------------------------------------------------------------------------
 > Jacek Kopecky <jacek@idoox.com>
 > Sent by: xml-dist-app-request@w3.org
 > 10/22/2001 09:58 AM
 >         To:     <xml-dist-app@w3.org>
 >         cc:     (bcc: Noah Mendelsohn/CAM/Lotus)
 >         Subject:        proposed resolution to issue #30
 > Hi, the ETF proposes the following resolution to issue #30:
 >  1) The editors shall
 >    a) remove the mentions of the attribute information items 'id'
 > and 'href' from sections 2 of both parts of the spec, for these
 > are encoding-specific attributes,
 >    b) add the text into section 4 of the Adjuncts, something
 > along the lines of
 >  "SOAP Encoding uses unqualified attribute information items with
 > a local name of id and a type of ID in the
 > http://www.w3.org/2001/XMLSchema namespace to specify the unique
 > identifier of an encoded element.
 >  SOAP Encoding uses unqualified attribute information items with
 > a local name of href and a type of anyURI in the
 > http://www.w3.org/2001/XMLSchema namespace to specify a reference
 > possibly to elements specified by and ID per above, possibly to
 > other (even external) resources, in a manner conforming to the
 > XML Specification, XML Schema Specification, and XML
 > Linking Language Specification.
 >  2) The issues-list maintainer (Hugo? 8) shall open an issue
 > according to the following copy of Noah's reaction (member-only
 > [1]) to my first proposed resolution:
 > ------------- Noah's issue
 >  I think we need to say a bit about which such URI's are
 > guaranteed derferenceable, and which not.  We may need to say
 > that the answer depends on features supported and/or binding.
 > For example, I hope it's guaranteed that with SOAP+Attachements
 > (a potential feature), references to attachements are guaranteed
 > to resolve.  On the other hand, I certainly wouldn't expect a
 > similar guarantee for a reference to w3.org, if I'm processing
 > the message on a Palm Pilot that is currently disconnected from
 > the rest of the Web.  The text you give is ambiguous, but could
 > lead readers to believe that Web connectivity is required to do
 > conforming processing of SOAP messages.  Thanks.
 >  ------------ end Noah's issue
 >                             Jacek Kopecky
 >                             Idoox
 >                             http://www.idoox.com/
 > [1] http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2001Oct/0113.html
Received on Tuesday, 23 October 2001 04:53:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:16 UTC