RE: [Bug 8180] New: Transfer: can a resource represenation be empty? from Ram Jeyaraman on 2010-01-26 (public-ws-resource-access@w3.org from January 2010)

From: Ram Jeyaraman <Ram.Jeyaraman@microsoft.com>
Date: Tue, 26 Jan 2010 14:57:34 +0000
To: "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
Message-ID: <503546C5699C1144BDEA0D0DFFE7F881184C25E2@TK5EX14MBXC119.redmond.corp.microsoft.>
The issue touches a few aspects:



·       Points to a few inconsistencies between schema outline and schema definition for some of the transfer messages.

o   Answer: The proposal below (points 1 through 3) addresses those inconsistencies.

·       Poses the question whether the representation could be empty?

o   Answer: Yes. In such a case, the representation (first child element) should be an empty tag. The proposal points 4 through 8 addresses this.

·       Poses the question how to distinguish extension elements from a representation (if present) in a message?

o   Answer: The specification clearly states that if there are child elements in a message, then the first child element MUST be the resource representation. This means, that if extension elements are used, the first child element MUST be the resource representation.



The proposal below aims to address the above concerns.



[1] Proposal



1)



Change:



Ø  [Action]
  http://www.w3.org/2009/09/ws-tra/GetResponse

[Body]
  <wst:GetResponse ...>
    xs:any*
  </wst:GetResponse>



To:



Ø  [Action]
  http://www.w3.org/2009/09/ws-tra/GetResponse

[Body]
  <wst:GetResponse ...>
    xs:any+
  </wst:GetResponse>



This ensures that the cardinality in the XML outline matches that in the schema definition.



2)



Change:


[Action]
  http://www.w3.org/2009/09/ws-tra/Put

[Body]
  <wst:Put Dialect="xs:anyURI"? ...>
    xs:any*
  </wst:Put>



To:


[Action]
  http://www.w3.org/2009/09/ws-tra/Put

[Body]
  <wst:Put Dialect="xs:anyURI"? ...>
    xs:any+
  </wst:Put>



This ensures that the cardinality in the XML outline matches that in the schema definition.



3)



Change:


  <xs:element name='PutResponse'>
    <xs:complexType>
      <xs:sequence>
        <xs:any minOccurs='1' namespace='##other' processContents='lax' />
      </xs:sequence>
      <xs:anyAttribute namespace='##other' processContents='lax' />
    </xs:complexType>
  </xs:element>



To:


  <xs:element name='PutResponse'>
    <xs:complexType>
      <xs:sequence>
        <xs:any minOccurs='0' namespace='##other' processContents='lax' />
      </xs:sequence>
      <xs:anyAttribute namespace='##other' processContents='lax' />
    </xs:complexType>
  </xs:element>



This ensures that the cardinality in the XML outline matches that in the schema definition.



4)



Change:


[Body]/wst:GetResponse
This REQUIRED element MUST have as its first child element, an element that comprises the representation of the resource.

To:


[Body]/wst:GetResponse
This REQUIRED element MUST have as its first child element, an element that comprises the representation of the resource. The first child element MAY be an empty element depending on the resource representation.

5)



Change:


[Body]/wst:Put
This REQUIRED element MUST have as its first child element, an element that comprises the representation of the resource that is to be replaced.

To:


[Body]/wst:Put
This REQUIRED element MUST have as its first child element, an element that comprises the representation of the resource that is to be replaced. The first child element MAY be an empty element depending on the resource representation.

6)



Change:


[Body]/wst:PutResponse
This REQUIRED element, if it contains any child elements, MUST have as its first child element, an element that comprises the representation of the resource that has been updated.



To:


[Body]/wst:PutResponse
This REQUIRED element, if it contains any child elements, MUST have as its first child element, an element that comprises the representation of the resource that has been updated. The first child element, if present, MAY be an empty element depending on the resource representation.

7)



Change:


[Body]/wst:Create
This REQUIRED element MAY contain zero or more child elements. If this element does not contain a child element then the resource will be created using default values. The first child element, if present, MUST be the literal resource representation, a representation of the constructor for the resource, or other instructions for creating the resource. If present, any extension elements MUST be included after the mandated first child element.

To:


[Body]/wst:Create
This REQUIRED element MAY contain zero or more child elements. If this element does not contain a child element then the resource will be created using default values. The first child element, if present, MUST be the literal resource representation, a representation of the constructor for the resource, or other instructions for creating the resource. The first child element, if present, MAY be an empty element depending on the resource representation. If present, any extension elements MUST be included after the mandated first child element.

8)



Change:


[Body]/wst:CreateResponse
This REQUIRED element MUST have as its first child element an Endpoint Reference (wst:ResourceCreated element) to the newly created resource.
A service MUST also return the current representation of the new resource as the second child of the wst:CreateResponse element if the created representation logically differs from the representation sent in the Create request message. That is, the initial representation is returned if one or more values present in Create message was specifically overridden with a different value during resource creation. If default values are used to complete a resource creation which were not present in the Create message, then this does not constitute a logical difference.

To:


[Body]/wst:CreateResponse
This REQUIRED element MUST have as its first child element an Endpoint Reference (wst:ResourceCreated element) to the newly created resource.
A service MUST also return the current representation of the new resource as the second child of the wst:CreateResponse element if the created representation logically differs from the representation sent in the Create request message. That is, the initial representation is returned if one or more values present in Create message was specifically overridden with a different value during resource creation. If default values are used to complete a resource creation which were not present in the Create message, then this does not constitute a logical difference. This second child element, if present, MUST be the current representation of the resource that was created. This second child element, if present, MAY be an empty element depending on the resource representation.

-----Original Message-----
From: public-ws-resource-access-notifications-request@w3.org [mailto:public-ws-resource-access-notifications-request@w3.org] On Behalf Of bugzilla@wiggum.w3.org
Sent: Wednesday, November 04, 2009 9:38 AM
To: public-ws-resource-access-notifications@w3.org
Subject: [Bug 8180] New: Transfer: can a resource represenation be empty?



http://www.w3.org/Bugs/Public/show_bug.cgi?id=8180



           Summary: Transfer: can a resource represenation be empty?

           Product: WS-Resource Access

           Version: FPWD

          Platform: PC

        OS/Version: Windows XP

            Status: NEW

          Severity: normal

          Priority: P2

         Component: Transfer

        AssignedTo: public-ws-resource-access-notifications@w3.org<mailto:public-ws-resource-access-notifications@w3.org>

        ReportedBy: dug@us.ibm.com<mailto:dug@us.ibm.com>

         QAContact: public-ws-resource-access-notifications@w3.org<mailto:public-ws-resource-access-notifications@w3.org>





The definitions of Get and Put imply, thru their schema, that a representation could be empty:



Get Response is defined as:

  <wst:GetResponse ...>

    xs:any*

  </wst:GetResponse>



Put is defined as:

  <wst:Put Dialect="xs:anyURI"? ...>

    xs:any*

  </wst:Put>



Put Response is defined as:

  <wst:PutResponse ...>

    xs:any*

  </wst:PutResponse>



We then have text similar to this:

--

[Body]/wst:Put

    This REQUIRED element MUST have as its first child element, an element that comprises the representation of the resource that is to be replaced. Additional extension elements MAY be included after the element representing the resource.

--



The MUST would seem to imply that some XML is required.  The schema seems to imply that it could be empty.  The text about extensions makes it really interesting since if the representation is empty then you can't tell if the element that is present is the representation or an extension.  We have a bit of ambiguity/confusion here.



Proposal:

Allow for empty representations, but leave it up to extensions to figure out how to know when their elements are extensions vs part of the resource.



So, as an example, modify Get Response from:

[Body]/wst:GetResponse

    This REQUIRED element MUST have as its first child element, an element that comprises the representation of the resource. Additional extension elements MAY be included after the element representing the resource.



to:

[Body]/wst:GetResponse

    This is a REQUIRED element. The resource representation, if any, MUST be its first child element. Additional extension elements MAY be included after the element representing the resource. If resource representation is empty then the extension specification MUST include a mechanism to ensure the extension elements are not mistakenly interpreted as the resource representation.



Make similar mods to the other ops as needed.





--

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email

------- You are receiving this mail because: ------- You are the QA contact for the bug.

You are the assignee for the bug.
Received on Tuesday, 26 January 2010 14:58:10 UTC