RE: [AF] relative URIs for attachments

Herve, pls incorporate this change into the Ed copy.


............................................
David C. Fallside, IBM
Ext Ph: 530.477.7169
Int  Ph: 544.9665
fallside@us.ibm.com



|---------+------------------------------>
|         |           Noah               |
|         |           Mendelsohn/Cambridg|
|         |           e/IBM@Lotus        |
|         |           Sent by:           |
|         |           xml-dist-app-reques|
|         |           t@w3.org           |
|         |                              |
|         |                              |
|         |           09/16/2002 12:02 PM|
|         |                              |
|---------+------------------------------>
  >---------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                           |
  |       To:       "Henrik Frystyk Nielsen" <henrikn@microsoft.com>                                                          |
  |       cc:       "Herve Ruellan" <ruellan@crf.canon.fr>, xml-dist-app@w3.org                                               |
  |       Subject:  RE: [AF] relative URIs for attachments                                                                    |
  |                                                                                                                           |
  |                                                                                                                           |
  >---------------------------------------------------------------------------------------------------------------------------|




I think this looks good, thanks!

Semi-unrelated to your changes, I'm a little unclear on whether there
really has to be just 1 URI to identify a part.  First of all, there is
the usual relative vs. absolute question, so at the reference end at least
there are potentially multiples.  Even beyond that, the web architecture
generally allows multiple URIs for a resource.  I think the right approach
is:

<NewSection4revisedAgain>
Each part is identified by one or more URIs (typically one) that can be
used to reference it from other parts. The URI(s) identifying a part can
be of any URI scheme. It is RECOMMENDED that only IANA registered URI
schemes be used.
</NewSection4revisedAgain>

<NewSection6revisedAgain>
A mechanism by which each part is identified using one (or more) URI(s).
The URI scheme used MAY but need not be the same for all parts. The URI
scheme used for multiple identifiers of a single part MAY but need not be
the same . If a SOAP binding allows the use of relative URIs, then the
binding MUST specify how the base URI is established.  NOTE:  the ability
to identify a single part with multiple URIs is provided because, in
general, the Web architecture allows such multiple names for a single
resource;  it is anticipated that most bindings will name each part with a
single URI, and through the use of base URIs, provide for absolute and/or
relative URI references to that URI.
</NewSection6revisedAgain>

I'm afraid it does make the whole thing clumsier, but I'm reluctant to
appear to restrict the web architecture.  The case that particularly
concerns me is where a binding accesses resources in a lazy manner,
pulling them only when referenced.  In this case, should we really be
mandating that the part known as
http://www.w3.org/TR/2000/REC-xml-20001006 cannot also be referenced in a
SOAP message as http://www.w3.org/TR/REC-xml (they are in fact the same
resource on the web at this time.)  Saying that each part has just one URI
rules out both of these references in a single envelope.  It's a seemingly
obscure case, but I think it's better on balance to take the trouble to
get it right.

Thanks.

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------





        "Henrik Frystyk Nielsen" <henrikn@microsoft.com>
        Sent by: xml-dist-app-request@w3.org
        09/15/2002 09:08 PM

                 To: "Herve Ruellan" <ruellan@crf.canon.fr>,
<xml-dist-app@w3.org>
                 cc:
                 Subject: RE: [AF] relative URIs for attachments




From an editorial and consistency point of view, I think it would be
beneficial to maintain the separation between the abstract description of
the compound SOAP structure and the requirements to a particular binding
implementing the feature. Currently we have section 4 describing the model
and section 6 describing the requirements to an implementation.

I suggest that relative URIs be mentioned in section 6 and not section 4
as we from a model perspective always are dealing with absolute URIs;
relative URIs are meaningless by themselves. Whether the absolute URIs can
be represented using a base URI and a relative URI is an implementation
issue and not a model issue.

Section 6 already provides requirements for dealing with URIs although it
doesn't mention the issue of relative URIs. I would therefore suggest the
following slight reorganization of your proposal:

<OldSection4>
Each part is identified by a URI that can be used to reference it from
other parts. The URI identifying a part can be of any URI scheme; the
particular assignment of URIs to parts in the message MUST be specified by
each SOAP binding implementing this feature. It is RECOMMENDED that only
IANA registered URI schemes be used.
</OldSection4>

<NewSection4>
Each part is identified by a URI that can be used to reference it from
other parts. The URI identifying a part can be of any URI scheme. It is
RECOMMENDED that only IANA registered URI schemes be used.
</NewSection4>

<OldSection6>
A mechanism by which each part is identified using a URI reference. While
the reference MUST be in the form of a URI, the URI scheme used MAY but
need not be the same for all parts.
</OldSection6>

<NewSection6>
A mechanism by which each part is identified using a URI. The URI scheme
used MAY but need not be the same for all parts. If a SOAP binding allows
the use of relative URIs, it MUST specify how the base URI is established.

</NewSection6>

Henrik

>-----Original Message-----
>From: Herve Ruellan [mailto:ruellan@crf.canon.fr]
>Sent: Thursday, September 12, 2002 05:27
>To: xml-dist-app@w3.org
>Subject: [AF] relative URIs for attachments
>
>
>
>Dear all,
>
>I currently have an action item:
>2002/09/11: Herve
>Draft clarifying sentence or two for AF spec that relative URIs are
>allowed by EOB Friday. Comments are due Monday noon PT.
>Silence is assent.
>
>Here is some proposal for fulfilling this action item.
>
>Comments are welcomed.
>
>Hervé.
>
>--------------------
>
>Change 5th paragraph of 4. Compound SOAP Structure Model:
><current>
>Each part is identified by a URI that can be used to reference it from
>other parts. The URI identifying a part can be of any URI scheme; the
>particular assignment of URIs to parts in the message MUST be
>specified
>by each SOAP binding implementing this feature. It is RECOMMENDED that
>only IANA registered URI schemes be used.
></current>
>
><proposal>
>Each part is identified by a URI reference that can be used to
>reference
>it from other parts. The URI reference identifying a part can
>be of any
>URI scheme. It can be an absolute or a relative URI. The particular
>assignement of URI references to parts in the message MUST be
>specified
>by each SOAP binding implementing this feature. In addition, if a SOAP
>binding allows the use of relative URIs, it MUST specify how the base
>URI is established. It is RECOMMENDED that only IANA registered URI
>schemes be used.
></proposal>
>
>I don't think we should change the definition of a Secondary
>Part which
>is currently (i.e. keep URI, and do not replace it by URI reference):
><current>
>Secondary Part
>
>A document or entity related to the primary SOAP message part in some
>manner. A secondary part is a resource in the sense that it
>has identity
>and is identified by a URI. The representation of the resource
>can be of
>any type and size. Secondary parts are informally referred to as
>attachments.
></current>
>
>

Received on Monday, 16 September 2002 18:25:30 UTC