Re: [apps-discuss] New Version Notification for draft-hamnaberg-publish-link-relation-00.txt

[Jan Algermissen <[e-mail]>]

On 16.01.2014, at 11:35, Graham Klyne <[e-mail]> wrote:

> [Slightly off-topic...]
> 
> Mike,
> 
> Accepting that the operational details be separate from the link relation semantics...
> 
> In your (REST-informed?) view, where the link relation occurs within some retrieved representation, would be be reasonable for the representation to *also* indicate the operations that might be applicable?  (Somewhat like HTML <form> @method, maybe.)
> 
> For example, to abuse an example from Darrel's draft [1]:
> 
>       <link rel="self" type="application/atom+xml"
>           href="http://example.org/feed"/>
>       <link rel="publish"
>         href="http://example.org/publish"/
>         method="POST" post_types="text/uri-list" />
> 
> ("method" and "post-types" here are pure invention for the purpose of discussion.)
> 
> So in this context, a client can move straight to the publication step, which I think is Darrel's goal with the operational discussion in the link relation.  In a different context, a client might have to perform a GET (or equivalent) to the linked resource to discover its affordances.

The problem is that you are making the specification of the link rel overly complex by extending already established linking specs.

If you want HTTP-header inline forms with similar semantics of HTML forms, I'd roll an I-D - but I would not try to bake it into something else using extensions.

As to why the operational semantics need not go into the rel spec, I just remembered this:

http://www.imc.org/atom-protocol/mail-archive/msg03925.html

in which Roy is touching the issue that you ust do not need to know operational semantics - it is a configuration-time issue (or call it introspection time).

Looking for tighter coupling by baking operational constraints into design time information is just trying to 'fix' the runtime uncertainty that REST deliberately makes explicit (REST aims to do away with the constraints because they are too constly to hold up in a decentralized environment).

Just assume the POST based on context and prepare the client that it might fail.

jan


> 
> #g
> --
> 
> [1] http://www.ietf.org/id/draft-hamnaberg-publish-link-relation-00.txt
> 
> On 15/01/2014 21:37, mike amundsen wrote:
>> I'm not a fan of using a string as a network affordance ;) I know this is
>> not a universally held conviction. for example, HAL relies on this very
>> notion quite heavily.
>> 
>> i assert the best way to use link relation values is as identifiers. The
>> registry let's use describe these values in a general way much the way a
>>  language dictionary (e.g. English, French, etc.) does. The way in which
>> the words are used, their intent, implied meaning, etc. are often based on
>> immediate context ("you owe me a payment" vs. "there is were you go to make
>> payments") and so forth.
>> 
>> To your last point, I think tying operational semantics to a link relation
>> is over-constraining and limits it's use over time. Esp. when the
>> operational semantics are tied to a single protocol or format. I prefer to
>> keep usage details separate from the registry of unique values.
>> 
>> 
>> 
>> 
>> 
>> mamund
>> +1.859.757.1449
>> skype: mca.amundsen
>> http://amundsen.com/blog/
>> http://twitter.com/mamund
>> https://github.com/mamund
>> http://linkedin.com/in/mamund
>> 
>> 
>> On Wed, Jan 15, 2014 at 3:58 PM, Darrel Miller <[e-mail]>wrote:
>> 
>>> Mike,
>>> 
>>> How do you feel about a link relation that says, if you do POST, it
>>> means this ...
>>> 
>>> If that concerns you then do you have suggestions on how the these
>>> link relations should work:
>>> 
>>> rel=payment        https://web-payments.org/specs/source/payment-links/
>>> rel=hub
>>> https://pubsubhubbub.googlecode.com/git/pubsubhubbub-core-0.4.html
>>> rel=oauth2-token
>>> http://tools.ietf.org/html/draft-wmills-oauth-lrdd-07#page-8
>>> 
>>> As far as I understand it, all of these have an associated meaning to
>>> a POST request.  Curiously, that meaning is not described in the rel
>>> relation registration, but in the specification that describes the
>>> protocol that uses the link relation.  This separation concerns me
>>> because we could end up with a situation where different protocols
>>> assign different interaction semantics to the same link relation.
>>> 
>>> Darrel
>>> 
>>> 
>>> 
>>> On Wed, Jan 15, 2014 at 1:05 PM, mike amundsen <[e-mail]> wrote:
>>>> My advice is to *not* attempt to constrain how the client or server
>>> behaves
>>>> when using the link relation (e.g. "client SHOULD use POST to ....",
>>> etc.).
>>>> 
>>>> Instead just define the link relation's meaning and let clients and
>>> servers
>>>> use that shared meaning to do whatever they want with it.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> mamund
>>>> +1.859.757.1449
>>>> skype: mca.amundsen
>>>> http://amundsen.com/blog/
>>>> http://twitter.com/mamund
>>>> https://github.com/mamund
>>>> http://linkedin.com/in/mamund
>>>> 
>>>> 
>>>> On Wed, Jan 15, 2014 at 11:45 AM, Jan Algermissen
>>>> <[e-mail]> wrote:
>>>>> 
>>>>> 
>>>>> On 15.01.2014, at 16:59, Erlend Hamnaberg <[e-mail]> wrote:
>>>>> 
>>>>>> 
>>>>>> My use case has been a schedule for a conference.
>>>>>> 
>>>>>> The program is built over time, but once it is done, I want to publish
>>>>>> it.
>>>>> 
>>>>> If publishing is done by the same server, I'd change a property of the
>>>>> program to tell the server that it should publish.
>>>>> 
>>>>> When on a nother server, I'd try to POST the program's representation,
>>>>> implicitly creating a new publishing job. That job will have a URI
>>> which I
>>>>> would use to observer the state of the job.
>>>>> 
>>>>> Having "publish" point to the publishing system might make sense, in
>>> that
>>>>> sense "publish" would identoty a "resource providing publishing
>>> services".
>>>>> 
>>>>> I'd ovoid to POST the URI to the publishing service if possible, because
>>>>> it reduces simpicity IMHO, because the publishing system will need to
>>> go and
>>>>> GET the resuorec to be published which feels unnatural to me.
>>>>> 
>>>>> How does that resonate with you?
>>>>> 
>>>>> Jan
>>>>> 
>>>>>> 
>>>>>> I could, of course, go through each session and publish it directly.
>>>>>> Each publishing step is then a state change for each session.
>>>>>> However, for a user interface can become cumbersome.
>>>>>> 
>>>>>> However, If I decide to model this as two separate URIs,
>>>>>> I may need a different mechanism.
>>>>>> 
>>>>>> Not sure I am able to explain this appropriately.
>>>>>> 
>>>>>> Erlend
>>>>> 
>>>>> _______________________________________________
>>>>> apps-discuss mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> apps-discuss mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>>> 
>>> _______________________________________________
>>> apps-discuss mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>> 
>> 
>> 
>> 
>> _______________________________________________
>> apps-discuss mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>> 
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss