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 14:55:47 UTC