- From: Doug Davis <dug@us.ibm.com>
- Date: Wed, 6 May 2009 18:45:02 -0400
- To: public-ws-resource-access@w3.org
- Message-ID: <OF2E3DC946.0A02787E-ON852575AE.007C03A2-852575AE.007CFB19@us.ibm.com>
The server. If the server supports both (meaning it accept both an
instruction and storing of xs:any) and the Body looks like:
<Body>
<doit xmlns="urn:foo"/>
</Body>
is it a chunk of XML or is it the "doit" instruction? It (the server)
can't tell.
thanks
-Doug
______________________________________________________
STSM | Standards Architect | IBM Software Group
(919) 254-6905 | IBM 444-6905 | dug@us.ibm.com
The more I'm around some people, the more I like my dog.
Geoff Bullen <Geoff.Bullen@microsoft.com>
Sent by: public-ws-resource-access-request@w3.org
05/06/2009 06:29 PM
To
Doug Davis/Raleigh/IBM@IBMUS, "public-ws-resource-access@w3.org"
<public-ws-resource-access@w3.org>
cc
Subject
RE: Issue 6712 Discussion and Proposal
> ? but doesn't provide a way to unambiguously know which it is.
Doug,
Who is it that has to unambiguously know? The client? The server? Each
of these does unambiguously know.
--Geoff
From: public-ws-resource-access-request@w3.org
[mailto:public-ws-resource-access-request@w3.org] On Behalf Of Doug Davis
Sent: Wednesday, May 06, 2009 3:22 PM
To: public-ws-resource-access@w3.org
Subject: RE: Issue 6712 Discussion and Proposal
Geoff,
that solution, while technically possible, implies that we can not use
Transfer the way it was designed. It says:
[Body]/wst:Create
If this REQUIRED element contains children then the first child MUST
be the literal resource representation, a representation of the
constructor for the resource, or other instructions for creating the
resource.
It allows for the immediate child of the Create element to be either the
XML or an instruction, but doesn't provide a way to unambiguously know
which it is.
thanks
-Doug
______________________________________________________
STSM | Standards Architect | IBM Software Group
(919) 254-6905 | IBM 444-6905 | dug@us.ibm.com
The more I'm around some people, the more I like my dog.
Geoff Bullen <Geoff.Bullen@microsoft.com>
05/06/2009 05:56 PM
To
Doug Davis/Raleigh/IBM@IBMUS
cc
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>,
"public-ws-resource-access-request@w3.org"
<public-ws-resource-access-request@w3.org>
Subject
RE: Issue 6712 Discussion and Proposal
> If I have a transfer service that is storing a blob of xml in a DB and
it allows the XML to be anything - how do I know if the client meant for
it to be stored "as is" or for the QName to indicate an instruction?
Assuming of course that the service supports instructions as well.
Doug,
The Transfer service is in control, it knows its own content, and it knows
the difference between blobs and instructions. If the situation quoted
above arises for a particular Transfer service, then it could easily
distinguish between blobs and instructions using some strategy such as:
Request from client to transfer service to create a blob:
[body]
<create>
<blob>
? contents of blob to be stored in DB (any XML can be put here) ?
</blob>
</create>
Request from client to transfer service to create resource using a set of
rules:
[body]
<create>
<MyInstructions>
? set of instructions defined here (only instruction specific XML
can be put here) ?
</MyInstructions>
</create>
From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Wednesday, May 06, 2009 7:54 AM
To: Geoff Bullen
Cc: public-ws-resource-access@w3.org;
public-ws-resource-access-request@w3.org
Subject: RE: Issue 6712 Discussion and Proposal
> Even HTTP itself has a "message format" flag - its called
"Content-Type".
Doug, it is good that you are wanting to model Transfer after HTTP. The
Content-Type field is used to indicate the media type of the underlying
data. The media type of a SOAP message is well defined. The type of the
first child element of a Create message can be inferred from the QName of
the first child element.
I wouldn't assume that ;-) I only mentioned it because I know you like to
make the comparison. I actually am not fond of it because you're being
very selective about which bits of HTTP to mimic - basically just the ones
you like and ignoring the others. For example, HTTP has the notion of
fragments - two different ways (# in the URL and Range headers).
As for the QName... see below.
> the QName of the child can tell you most everything you need to know -
however, the one case of the resource being an xs:any is still left
ambiguous
Why is this ambiguous and to whom is it ambiguous? Even though it has
been defined as an xs:any in the Transfer schema, it is clearly defined by
the Service that implements it (this is stated by the spec). It is not
ambiguous to the Service at all, nor the client, since the client knows
what the Service demands.
If I have a transfer service that is storing a blob of xml in a DB and it
allows the XML to be anything - how do I know if the client meant for it
to be stored "as is" or for the QName to indicate an instruction? Assuming
of course that the service supports instructions as well.
thanks
-Doug
______________________________________________________
STSM | Standards Architect | IBM Software Group
(919) 254-6905 | IBM 444-6905 | dug@us.ibm.com
The more I'm around some people, the more I like my dog.
Geoff Bullen <Geoff.Bullen@microsoft.com>
05/06/2009 10:39 AM
To
Doug Davis/Raleigh/IBM@IBMUS
cc
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>, "
public-ws-resource-access-request@w3.org" <
public-ws-resource-access-request@w3.org>
Subject
RE: Issue 6712 Discussion and Proposal
> Even HTTP itself has a "message format" flag - its called
"Content-Type".
Doug, it is good that you are wanting to model Transfer after HTTP. The
Content-Type field is used to indicate the media type of the underlying
data. The media type of a SOAP message is well defined. The type of the
first child element of a Create message can be inferred from the QName of
the first child element.
> the QName of the child can tell you most everything you need to know -
however, the one case of the resource being an xs:any is still left
ambiguous
Why is this ambiguous and to whom is it ambiguous? Even though it has
been defined as an xs:any in the Transfer schema, it is clearly defined by
the Service that implements it (this is stated by the spec). It is not
ambiguous to the Service at all, nor the client, since the client knows
what the Service demands.
--Geoff
From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Tuesday, May 05, 2009 3:11 PM
To: Geoff Bullen
Cc: public-ws-resource-access@w3.org;
public-ws-resource-access-request@w3.org
Subject: Re: Issue 6712 Discussion and Proposal
This does not address the usecase that I'm worried about [1] nor the
issue. Even HTTP itself has a "message format" flag - its called
"Content-Type". In cases where there are multiple ways to interpret the
data (which is something that Transfer itself promotes) it only seems
logical for Transfer to provide the mechanism by which users of the spec
can do that. We don't need to specify much since the QName of the child
can tell you most everything you need to know - however, the one case of
the resource being an xs:any is still left ambiguous.
[1]
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0142.html
thanks
-Doug
______________________________________________________
STSM | Standards Architect | IBM Software Group
(919) 254-6905 | IBM 444-6905 | dug@us.ibm.com
The more I'm around some people, the more I like my dog.
Geoff Bullen <Geoff.Bullen@microsoft.com>
Sent by: public-ws-resource-access-request@w3.org
05/05/2009 01:05 PM
To
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
cc
Subject
Issue 6712 Discussion and Proposal
After further consideration of Issue 6712 (
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6712), which concerns the
Create message in Transfer, we don?t really think it matters if the spec
is inferring that a given service or resource can support more than one
format of Create Message or not. First, a few assumptions:
a) Each Service is ultimately responsible for deciding what type and
format of information is sent in a Create message.
b) Each Service will define its own set of ?creation rules? (if any)
which will be used to create its resources. That is, the WG will not
define some common creation rules language that will be used by all
resources. A Service may even support more than one format of creation
rules if it wants to.
Since the service is responsible for providing the definition of each
Create message format it supports, it is also responsible for demining how
it will tell the difference between those multiple formats when they occur
in a Create message. One way that the service might easily do this is as
follows:
Defining the literal Resource to create:
[Header]
<wsam:Action>?/ws-tra/Create</wsam:Action>
[Body]
<Create>
<xxx:MyResource>
Resource Definition here
</xxx:MyResource>
</Create>
Defining a set of rules to create a Resource:
[Header]
<wsam:Action>?/ws-tra/Create</wsam:Action>
[Body]
<Create>
<xxx:MyRules>
Rules here
</xxx:MyRules>
</Create>
In the end, there is no real difference between these two examples. It is
not clear then what the value is in providing a means within the protocol
for determining the message format (e.g. a resource or rule flag). Since
the resource (service) is responsible for the definition of both
?MyResource? and ?MyRules? there is literally nothing extra in the
Transfer protocol that is needed to help the resource understand the type
of ?instructions? it has been sent in a Create message. To add some flag
to the Transfer protocol seems purely redundant and unnecessary.
Based on the feedback from the WG, it does seem like some clarifying text
is required, we propose:
[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, is
service-specific (or the interpretation of the first child element is
defined by the resource to which the create message is addressed) and MUST
be the literal resource representation, a representation of the
constructor for the resource, or other instructions for creating the
resource. Additional extension elements MAY be included only after the
mandated first child element.
--Geoff
Received on Wednesday, 6 May 2009 22:47:06 UTC