Wf-XML and Hypermedia

[cappelaere]

Mark,

Thank you for your feedback. We had noticed your commnet on
http://www.infoq.com/news/2008/05/wfxml-r and did not knwo how to
respond to it. This is certainly the best place to discus these
issues.

The proposed protocol is actually supported by APP (Atom Publishing
Protocol). There is a service document that ought to be used by a
client to discover the links provided by the server.
The link to that document is (or ought to be :) discoverable in the
headers of the first page.
See http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-14.html#appdocs

I hope this addresses your concerns.

Thanks again for your kind feedback,

Regards,
Pat.

> From: Mark Baker <mba...@gmail.com>
> Date: Mon, 2 Jun 2008 20:31:16 -0700 (PDT)
> To: cappelaere <cappe...@gmail.com>
> Subject: Re: Version 0.4
>
> Kudos for trying REST on for size, folks ...
>
> I haven't had a detailed look at the spec, but my initial scan
> identified what seems a pretty significant issue. AFAICT, you seem to
> be standardizing portions of URI names, e.g. "./workflows" or "./
> definitions". One of REST's constraints - in fact, probably it's
> single most important constraint - is called "hypermedia as the engine
> of application state", and it means that clients make progress through
> an application state machine *only* by following links provided the
> server. If a client uses a priori knowledge of the URI structure of
> the server, then that isn't REST, for the same reason that well known
> URIs like "robots.txt" and "favicon.ico" aren't REST: it dramatically
> increases coupling between client and server, preventing their
> implementations from evolving independently.
>
> So instead of standardizing "./workflows", instead define a document
> data element that can be used to assert that some particular URI
> identifies a workflow container, something like;
>
> <workflow href="http://example.com/foo/bar/my-workflow-container" /
>>
>
> If I've misunderstood based on my incomplete review of the spec, my
> apologies.
>
> Mark.

[John Mettraux]

>> From: Mark Baker <mba...@gmail.com>
>> Date: Mon, 2 Jun 2008 20:31:16 -0700 (PDT)
>> To: cappelaere <cappe...@gmail.com>
>> Subject: Re: Version 0.4
>>

>> I haven't had a detailed look at the spec, but my initial scan
>> identified what seems a pretty significant issue. AFAICT, you seem to
>> be standardizing portions of URI names, e.g. "./workflows" or "./
>> definitions". One of REST's constraints - in fact, probably it's
>> single most important constraint - is called "hypermedia as the engine
>> of application state", and it means that clients make progress through
>> an application state machine *only* by following links provided the
>> server. If a client uses a priori knowledge of the URI structure of
>> the server, then that isn't REST, for the same reason that well known
>> URIs like "robots.txt" and "favicon.ico" aren't REST: it dramatically
>> increases coupling between client and server, preventing their
>> implementations from evolving independently.

Mark,

AtomPub has its service document as an entry point. What would you
recommend as an entry point for a RESTful service not using AtomPub ?
By "entry point" I mean where the links to follow are initially
exposed, GET /. Any best practice ?

Best regards,

--
John Mettraux - http://jmettraux.wordpress.com

[Mark Baker]

On Tue, Jun 3, 2008 at 7:08 AM, cappelaere <cappe...@gmail.com> wrote:
> Mark,
>
> Thank you for your feedback. We had noticed your commnet on
> http://www.infoq.com/news/2008/05/wfxml-r and did not knwo how to
> respond to it. This is certainly the best place to discus these
> issues.
>
> The proposed protocol is actually supported by APP (Atom Publishing
> Protocol). There is a service document that ought to be used by a
> client to discover the links provided by the server.
> The link to that document is (or ought to be :) discoverable in the
> headers of the first page.
> See http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-14.html#appdocs
>
> I hope this addresses your concerns.
>
> Thanks again for your kind feedback,

Thanks, Pat, that's good news indeed. I would highly recommend
though, that you remove all references to even suggested relative URI
paths (except for examples that are clearly marked as such) lest some
implementer get the same impression that I did.

FWIW, ironically, I just noticed another instance of this in the
discovery API section, 5.1. where it says "The proposed location for
the Service document is http://
{server}/{service}/app".

Mark.

[Keith]

My take on the reading is that in order to use the service, you only
need to "know" about the service document, and that you presumably got
from some directory or registry (or possibly simply an informative web
page). Using that one address, you can discover the rest.

The original document strongly implies that certain address patterns
are required, but the rewrite of the document should include
statements that the actual address is not fixed to a particular value,
and your client must not assume that it is fixed.

This does, however, then raise the issue that there must be a type
system to identify the "service type", so that we can identify the
service that lists process instances, and distinguish this from the
service that lists process definitions. It seems reasonable to
standardize a set of keywords to identify these.

-Keith

On Jun 3, 7:28 am, "Mark Baker" <mba...@gmail.com> wrote:

> On Tue, Jun 3, 2008 at 7:08 AM, cappelaere <cappela...@gmail.com> wrote:
> > Mark,
>
> > Thank you for your feedback. We had noticed your commnet on

> >http://www.infoq.com/news/2008/05/wfxml-rand did not knwo how to

> > respond to it. This is certainly the best place to discus these
> > issues.
>
> > The proposed protocol is actually supported by APP (Atom Publishing
> > Protocol). There is a service document that ought to be used by a
> > client to discover the links provided by the server.
> > The link to that document is (or ought to be :) discoverable in the
> > headers of the first page.

> > Seehttp://bitworking.org/projects/atom/draft-ietf-atompub-protocol-14.ht...