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

[Graham Klyne <[e-mail]>]

[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.

#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
>