akuchlin@... wrote:
>
> On Tue, Feb 19, 2002 at 04:57:00PM -0800, Paul Prescod wrote:
> >http://www.prescod.net/wrdl.html
>
> Hmmm... I'm trying to wrap my head around this.

It's very rough right now. Release early and often. It's changed its
name three times this week. ;) More a direction to get people thinking
then something clearly implementable.

> * In the example, purchaseOrder has the query string declared as type
> integer. In the invocation example, at no point is this integer parameter
> supplied.

Yeah, I didn't align the examples. That's confusing. For now I'll
mention that fact and then later I'll go through and do that.

> * I don't understand the match attribute of 'representation'; does it mean
> that "if the XPath expression returns a non-empty set of nodes, the
> document is considered to match this representation type. The set
> of matching nodes is then discarded, having served its purpose."

Now that you mention it, the equivalent in XSLT is not exactly match but
"test"

http://www.w3schools.com/xsl/xsl_if.asp

I'll add a pointer to that for those who don't know XSLT.

> * I also don't understand the sentence about " This is not a problem
> because representations are only checked in a boolean fashion..."
> This doesn't clarify what happens if a document matches multiple
> representation types; is it considered to be all of those matching types,
> or just one of them?

At the time I wrote that it really didn't matter. It's like a type check
of whether a thing is an integer or a float. As long as it matches you
don't really care. Once the API is flushed out we might start caring
because coding is easier if you can ask "what's this I've got" instead
of looking at the elements and attributes. But then maybe that should be
left to an orthogonal (but integrated) XML data binding layer.

> * How do you know when a new resource has been created in response to
> some request? Is that indicated in the returned document in some way
> dependent on its schema? (Say, if it has a <new-resource> element in it.)
> Or is it an HTTP header or something like that?

Have to think a little bit more about that to check whether I've got it
right...

The only methods that really create new resources are PUT and POST. PUT
always creates a new resouce unless it fails. POST returns a Location:
header. I've been back and forth over and over again on whether this
needs to be declared in advance and what it means for the API.

View 1:

The Location: header is probably irrelevant...the representation
returned by POST should point to the new thing that's created. Do you
care whether it really, really created something new or if it happened
to point to something it already had?

View 2:

HTTP privileges a particular URI in the entity as the "location" URI. I
think that logically everything else in the entity is just wrapping
around that main URI. So "creation" is important and should have
first-class support.

This minute View 2 is stronger in my mind.

> * In the 'po' representation type, what are the approve and cancel
> references intended to be, semantically? Are they resources that you could
> POST to in ordr to approve or cancel the order, or something else?

Yes, they are sort of trigger resources. Since REST-style denies you the
luxury of attaching arbitrary methods to resource you "run out" of
methods sometimes. So you either

a) pull this trick
b) do RPC (POST a do-what-I want)
or
c) think of a noun-ification of what you want and POST it. As in post a
"CANCELLED-PO resource". I'm not sure if this is really different than
RPC.

I think this trick is best because when we get event-handling and
orchestration integrated you'll be able to set up a chain of events so
that when resource A changes it triggers a POST to one of these trigger
resources. So you could say that when the boss's digital signature
resource appears in one place the approval method is triggered
automatically.

> (Having them be xsltResources makes it really unclear what they're
> supposed to be.)

Typo. I'll change those to "digitalSignatureResource" to be more
realistic. And really they could respond to PUT instead of POST. This
make sense to you:

<resourceType name="digitalSignature"
representations="some-dsig-standard">
<method name="PUT"/>
</resourceType>

> * Am I going to have to invent 187 different schemas for an application?
> Say a resource has a bunch of subresources: an owner, a history, etc.
> Some of these might use an existing schema -- RDF, HTML, whatever --
> but some might return something simple or ad hoc, such as just a
> string or an integer. Do I have to dress up this return value as:
>
> <dummy-root>http://newuri/</dummy-root>
> <dummy-root>35</dummy-root>
>
> Or could I declare "treat the body of this action as a string/integer/
> new URI"?

Several answers to this:

1. I would expect these minor sub-resources to be grouped into a single
logical object. REST encourages coarse-grained, not fine-grained
interactions -- big difference from RPC.

2. I may one day add WebDAV support. WebDAV is very REST-y in that it is
an HTTP extension even if it is not perfectly REST-y. And it has a
first-class notion of properties.

3. But even to do that ad-hoc stuff you don't need 187 schemas. You can
use the XML-RPC or SOAP encoding or WDDX schema for hundreds of ad-hoc
apps. Or just define a schema where <xsd:integer> is of type
<xsd:integer> etc.

4. You could also use MIME-RPC media-types instead of XML at all.
http://www.mime-rpc.com/protocol.html

> I have a project currently specified as a set of XML-RPC interfaces;
> RESTifying it will make an interesting thought experiment.

Cool. I don't always suggest switching from XML-RPC to REST, though. The
terminology I use (now) is that XML-RPC is better for "cross-network
scripting" and REST is for building big, long-lived, scalable,
extensible apps.

I'll fix those bugs. Pedagogic ones are more important at this stage
than ambiguities because it is more a thought experiment than a real
spec.

Paul Prescod