On Tue, Jan 10, 2012 at 10:14 AM, Markus Lanthaler
<markus.lanthaler@...> wrote:
>> > I think this is the very essence of our different POVs.
>> >
>> > What is an "navigation experience" in an M2M scenario. If there is a
>> link
>> > all I can do is to dereference it (by whatever method I choose to
>> use) a
>> > process the retrieved representation or ignore it. This is
>> independent of
>> > whether it is LE or LO according to your classification. Do you
>> disagree?
>> >
>>
>> fwiw, I agree apart from 'framing' LE mechanisms that actually prevent
>> subsequent requests from being necessary.
>
> Yes, if it is guaranteed that dereferencing the "self" link of an embedded
> resource (as in the HAL examples) returns exactly the same representation -
> which usually isn't guaranteed. If just a subset is embedded it might still
> be necessary to dereference to get all the data and then again it's just a
> link.
>

Right, the embedded resources are effectively a form of link and
should be used that way by clients if the embedded representation is
not sufficient for their needs. HAL doesn't provide any  guarantee of
completeness for the same reason an HTTP response doesn't guarantee
anything about the target of Content-Location.

So you are agreeing here that 'framed' embedding is a form type of LE
that is distinct from LO, even in a m2m context?

In my experience it is a very common requirement to optimise
applications this way, which is why I put it into HAL.

Out of interest - is it possible to do this with RDFa? how would that work?

> Right, the embedded resources are effectively a form of link and
> should be used that way by clients if the embedded representation is
> not sufficient for their needs. HAL doesn't provide any  guarantee of
> completeness for the same reason an HTTP response doesn't guarantee
> anything about the target of Content-Location.
>
> So you are agreeing here that 'framed' embedding is a form type of LE
> that is distinct from LO, even in a m2m context?

I'm not sure about this. You could also see that framed embedding as a form
of pagination which is in turn again LO in my opinion. So I'm still
struggling to see any form of LE. A link is a pointer to another resource
(or possibly also to the containing resource itself). You either have a
pointer to the data or directly the plain data.


> In my experience it is a very common requirement to optimise
> applications this way, which is why I put it into HAL.

Agree completely with that and that's one point where RESTful services
surely lack behind normal Web pages (think of image sprites).


> Out of interest - is it possible to do this with RDFa? how would that
> work?

Sure, you just include some triples of the other resource in the current
representation:

<div xmlns:foaf="http://xmlns.com/foaf/0.1/" about="#me" rel="foaf:knows">
    <ul>
       <li about="http://example/markus#me" typeof="foaf:Person">
         <a property="foaf:name" rel="foaf:homepage"
href="http://www.markus-lanthaler.com/">Markus</a>
       </li>
       <li about="http://example/bob#me" typeof="foaf:Person">
         <a property="foaf:name" rel="foaf:homepage"
href="http://example.com/bob">Bob</a>
       </li>
    </ul>
</div>

I posted it also here where it might be easier to read:
http://pastebin.com/qwxXbE6U

Nothing prevents you to lookup http://example/markus#me for more information
about that embedded resource.


--
Markus Lanthaler
@markuslanthaler

On Tue, Jan 10, 2012 at 10:50 AM, Markus Lanthaler
<markus.lanthaler@...> wrote:
>> Right, the embedded resources are effectively a form of link and
>> should be used that way by clients if the embedded representation is
>> not sufficient for their needs. HAL doesn't provide any  guarantee of
>> completeness for the same reason an HTTP response doesn't guarantee
>> anything about the target of Content-Location.
>>
>> So you are agreeing here that 'framed' embedding is a form type of LE
>> that is distinct from LO, even in a m2m context?
>
> I'm not sure about this. You could also see that framed embedding as a form
> of pagination which is in turn again LO in my opinion. So I'm still
> struggling to see any form of LE. A link is a pointer to another resource
> (or possibly also to the containing resource itself). You either have a
> pointer to the data or directly the plain data.
>
>
>> In my experience it is a very common requirement to optimise
>> applications this way, which is why I put it into HAL.
>
> Agree completely with that and that's one point where RESTful services
> surely lack behind normal Web pages (think of image sprites).
>
>
>> Out of interest - is it possible to do this with RDFa? how would that
>> work?
>
> Sure, you just include some triples of the other resource in the current
> representation:
>
> <div xmlns:foaf="http://xmlns.com/foaf/0.1/" about="#me" rel="foaf:knows">
>   <ul>
>      <li about="http://example/markus#me" typeof="foaf:Person">
>        <a property="foaf:name" rel="foaf:homepage"
> href="http://www.markus-lanthaler.com/">Markus</a>
>      </li>
>      <li about="http://example/bob#me" typeof="foaf:Person">
>        <a property="foaf:name" rel="foaf:homepage"
> href="http://example.com/bob">Bob</a>
>      </li>
>   </ul>
> </div>
>
> I posted it also here where it might be easier to read:
> http://pastebin.com/qwxXbE6U
>
> Nothing prevents you to lookup http://example/markus#me for more information
> about that embedded resource.

Ok thanks - how would you present that as JSON-LD?

> > I posted it also here where it might be easier to read:
> > http://pastebin.com/qwxXbE6U
> >
> > Nothing prevents you to lookup http://example/markus#me for more
> information
> > about that embedded resource.
>
> Ok thanks - how would you present that as JSON-LD?

It's quite similar (http://pastebin.com/f11Av1Jx), without using prefixes
you would end up with something like:

{
   "@context": {
     "homepage": { "@id": "http://xmlns.com/foaf/0.1/homepage", "@type":
"@id" },
     "know": "http://xmlns.com/foaf/0.1/knows",
     "name": "http://xmlns.com/foaf/0.1/name"
   },
   "@id": "#me",
   "know": [
     {
       "@id": "http://example/bob#me",
       "name": "Bob",
       "homepage": "http://example.com/bob"
     },
     {
       "@id": "http://www.markus-lanthaler.com/#me",
       "name": "Markus",
       "homepage": "http://www.markus-lanthaler.com/"
     }
   ]
}

If you have multiple of these representations you might consider putting the
context in an external file and just reference it.



--
Markus Lanthaler
@markuslanthaler

Inline

On Tue, Jan 10, 2012 at 2:39 AM, Markus Lanthaler
<markus.lanthaler@...> wrote:
> On Tuesday, January 10, 2012 3:11 PM, mike amundsen wrote:
>> Markus:
>> ok, let me ask you directly, can you imagine any circumstance where
>> the differences between transclusion (LE) and navigation (LO) "matter"
>> in an M2M scenario? mca
>
> Hmm.. honestly I can't come up with any scenario where the difference
> matters. Let's take an example from the H Factor page [1]:
>
>  LE: <img src="http://www.example.org/images/logo" title="company logo" />
>
> Would the following be any different from a M2M POV? Would it render some
> functionality impossible?
>

The way I build hypermedia driven clients, it makes a huge difference
whether a link is an LE or an LO.  When I do an LO,  my client is
moving to a new state based on the response from the server.  Any
links that were previously available in the client's previous state
are potentially no longer valid.  However, if I do an LE I am simply
augmenting the clients current state with some additional information.

Consider the scenario where the user-agent is in a state where there
are two possible LO transitions rel="submit-order"
rel="change-quantity" and a LE rel="product-details".  If I request
the "product-details" then the client knows that both "submit-order"
and "change-quantity" are still valid.  However, if the client follows
"submit-order" and the returned response does not include a
rel="change-quantity" then it would be wise for the client not to
attempt to try and follow that link.

Darrel

> The way I build hypermedia driven clients, it makes a huge difference
> whether a link is an LE or an LO.  When I do an LO,  my client is
> moving to a new state based on the response from the server.  Any
> links that were previously available in the client's previous state
> are potentially no longer valid.  However, if I do an LE I am simply
> augmenting the clients current state with some additional information.
>
> Consider the scenario where the user-agent is in a state where there
> are two possible LO transitions rel="submit-order"
> rel="change-quantity" and a LE rel="product-details".  If I request
> the "product-details" then the client knows that both "submit-order"
> and "change-quantity" are still valid.  However, if the client follows
> "submit-order" and the returned response does not include a
> rel="change-quantity" then it would be wise for the client not to
> attempt to try and follow that link.

Agree, but IMO that is domain specific information and not protocol-level
information as per Mikes distinction.
The discussion was whether a media type needs the distinction of LE/LO at
the protocol level, i.e. <img> vs. <a>, or whether that is (solely) domain
specific information.



--
Markus Lanthaler
@markuslanthaler

Hi,

On 1/10/2012 3:08 PM, Darrel Miller wrote:

[snip]

> The way I build hypermedia driven clients, it makes a huge difference
> whether a link is an LE or an LO. When I do an LO, my client is
> moving to a new state based on the response from the server. Any
> links that were previously available in the client's previous state
> are potentially no longer valid. However, if I do an LE I am simply
> augmenting the clients current state with some additional information.
>
> Consider the scenario where the user-agent is in a state where there
> are two possible LO transitions rel="submit-order"
> rel="change-quantity" and a LE rel="product-details". If I request
> the "product-details" then the client knows that both "submit-order"
> and "change-quantity" are still valid. However, if the client follows
> "submit-order" and the returned response does not include a
> rel="change-quantity" then it would be wise for the client not to
> attempt to try and follow that link.

I get the impression that the problem with link relations types is that
they are utilised for both domain-level semantics (these are
relations/properties analogue to RDF properties in ontologies) and
application/protocol-level semantics* (e.g., "edit", "submit-order",
"change-quantity"). Where the former ones only have a descriptive
purpose ("meaning"), the latter ones are actions for the control
flow/application state (which are usually not part of RDF vocabularies
now-a-days).
It might be better to differentiate them, e.g., via 'rel' (for
domain-level semantics) and 'action-rel' (or simply 'action'; for
application/protocol-level semantics). Of course, one could also
describe them in a vocabulary.

Cheers,


Bo


*) yes, they are also domain-dependent/on the domain-level, but they are
actions

PS: relevant to this issue are maybe the following sources as well

[1] http://www.w3.org/wiki/RdfAffordances
[2] http://vocab.deri.ie/rdforms
[3] http://vocab.deri.ie/raul

wow!

from what i can glean in your reply, your operational definitions for
"problem domain" and "application" are no where near what i use.

i'll cry "uncle" here and cede the field to you.

mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me




On Tue, Jan 10, 2012 at 18:01, Peter Williams <pezra@...> wrote:
>
>
> On Tue, Jan 10, 2012 at 2:22 PM, mike amundsen <mamund@...> wrote:
>>
>> i am also confident i can implement multiple instances (multiple
>> applications) of the accounting problem domain using a different set of
>> affordances within the same protocol (i.e. HTTP w/ HTML-only, HTTP with ajax
>> scripting, HTTP w/ native (C,Java, etc.).
>
>
> Are you sure those would actually be accounting applications? I would tend
> to think of each of those (with the possible exception of the w/ native
> version) as interactive human user interface applications. The translation
> from the ui domain (of HTML) to accounting domain happens in the users head
> (the probably on the server), rather than the clients.
>
>>
>> what i suspect you are talking about is the mapping of the problem domain
>> to a _media_type_ (i.e HTML, Atom, etc.) in which the semantics of both the
>> problem domain and the target protocol are then _bound_ together.
>
>
> I guess i am arguing a media type can only be used to produce applications
> for one problem domain.
>
> Peter
> barelyenough.org
>

Mike,

> i'll cry "uncle" here and cede the field to you.

Perhaps this thread of the discussion has gone past the point of
usefulness. I was, of course, pushing the argument a bit beyond what
seems reasonable to see if it would break. Unfortunately, i am not
sure if it did.


I would like to go back to a question i asked earlier, if you don't
mind, regarding the distinction between embed and navigation links.

You often speak of the affordances provided by media types. I am not
sure i see the same set of affordances you do, or at least not in the
same way. In the physical world some affordances are possible because
of the laws of nature or the evolution of the human body, other are
based purely on cultural convention (eg, up usually maps to forward).
I think the "embed" link affordance is based on a set of cultural
conventions (img usually maps to embed).

However, which culture a client belongs to depends on what it is
trying to accomplish and what technology it uses. So different clients
might interprete the same feature as a different affordance. Proxies
do not transclude any representations in html, regardless of the
flavor of those links. Screen readers have no need to transclude
images in HTML. Nor do (most) automated user agents, for that matter.
To those clients the `img` element affords navigation, not embedding.

Are these clients wrong/broken when they choose to treat a "embed"
link as a "navigation" link?

Under what circumstances would it be wrong/broken for a client to
transclude a "navigation" link if it could successfully interpret the
resulting document?

Peter
barelyenough.org

On Wednesday, January 11, 2012 5:22 AM, mike amundsen wrote:
> i suspect the terms "protocol", "domain", and "application"
> are insufficiently defined for this discussion.
>
> using the definitions of these terms that i carry in my head today:
>
> i can think of quite a number of cases where the problem domain
> (accounting, warehouse mgmt, shopping, etc) and the protocol
> (FTP, HTTP, SMTP, rsync, etc.) are completely independent.

We were not speaking of the protocol in that sense, were we? I thought the
discussion was about "protocol-level information" in media types.


> for example, i am quite confident i can complete a successful
> implementation (an "accounting application") of the accounting problem
> domain for a distributed system using more than one protocol. 

Agree


> i am also confident i can implement multiple instances (multiple
> applications) of the accounting problem domain using a different set
> of affordances within the same protocol (i.e. HTTP w/ HTML-only, HTTP
> with ajax scripting, HTTP w/ native (C,Java, etc.).

Here you begin mixing protocols and media types.


> what i suspect you are talking about is the mapping of the problem domain
> to a _media_type_ (i.e HTML, Atom, etc.) in which the semantics of both
the
> problem domain and the target protocol are then _bound_ together.

I think that was what the discussion was about. It was about whether a media
type can contain problem domain independent support for LE and LO. My
argument was that this is impossible since the semantics of the problem
domain specify what a client does with the link target. You argue (at least
that's my understanding) that a media type is able to specify without any
specific problem domain semantics whether a link is LE or LO.


To answer Darrel's earlier question:

>> "What is an "navigation experience" in an M2M scenario. If there is a
link
>> all I can do is to dereference it (by whatever method I choose to use) a
>> process the retrieved representation or ignore it. This is independent of
>> whether it is LE or LO according to your classification. Do you
disagree?"
>>
> From the perspective of a client that conforms to the hypermedia
constraint,
> I would disagree.  De-referencing a LO has a different effect on the
client
> state than de-referencing an LE.

I agree, but that entirely depends upon the client. The server should not
even know what the client is doing. Putting that information on the server
side doesn't make any sense to me.

Imagine a client whose task it is to retrieve the first embedded image in a
given Web page. I think you would agree that even though the server
specifies it as <img>, i.e., LE the client state would be changed to
"success" after retrieving that image. Or do you disagree with that?

So my argument was that it is impossible to specify on the server side
whether a link is LE or LO because it is entirely up to the client to do
decide how the link is interpreted. All the server can do is to describe the
"meaning" respectively the relation of the link to the current
representation.



--
Markus Lanthaler
@markuslanthaler

Hi,

On 1/11/2012 3:40 AM, Markus Lanthaler wrote:

[snip]

> So my argument was that it is impossible to specify on the server side
> whether a link is LE or LO because it is entirely up to the client to do
> decide how the link is interpreted. All the server can do is to describe the
> "meaning" respectively the relation of the link to the current
> representation.

I think there are some interpretation problems with LE and LO. When we
discussed this issue yesterday at the #rest channel at freenode (see
[1]), I came up with some definitions that made sense for some of the
channel members (at least ;) ):

1. a "navigation link" (LO) can be interpreted as "push application into
a next state", e.g. "submit-order"
2. an "embedded link" (LE) can be interpreted as "deliver information to
be able to push application into a next state", this could maybe also
"include"

=> I would especially vote for renaming LE to "transclusion link"

In hypermedia media types the link type/intent could be derived from the
surrounding tag (+ further attribute values of that tag (instance)) that
includes a target resource as a value of a attribute.

  From a data-only perspective we do not need to differentiate link
types. However, it is useful to do this in a hypermedia environment to
specify it's intended purpose (i.e. in this context it doesn't matter
how a caching server processes this link, because this is not the place
where the application state would/could be changed).

Cheers,


Bo


[1] http://rest.hackyhack.net/2012-01-10.html#320/h320,407

Hi Peter,

On 1/10/2012 9:56 PM, Peter Williams wrote:

[snip]

> Are there examples of media type features that have domain, application
> or protocol only semantics that i have missed?
>

RDF includes only "domain"/description-level semantics*. The tipping
point is RDF itself is a knowledge representation structure/knowledge
representation language and not a media type. However, RDF
serialisation/representation formats are media types, e.g. Turtle or
RDF/XML.


*) the crux is that since one could describe everything one could
describe application-level semantics with RDF as well :)

=> so it's really hard to draw a line

I think a good example is RDFa that could be integrated into other
existing markup media types, e.g., XHTML+RDFa (see also  [1]). So one
could integrate RDFa in, e.g., XAML as well (if needed).

Cheers,


Bo


[1] http://www.w3.org/TR/rdfa-core/ "RDFa Core is a specification for
attributes to express structured data in any markup language."

Hi Darrel,

On 1/10/2012 9:33 PM, Darrel Miller wrote:
> On Tue, Jan 10, 2012 at 1:25 PM, Bob Ferris <zazi@...
> <mailto:zazi@...>> wrote:
>
>     __
>     I get the impression that the problem with link relations types is that
>     they are utilised for both domain-level semantics (these are
>     relations/properties analogue to RDF properties in ontologies) and
>     application/protocol-level semantics* (e.g., "edit", "submit-order",
>     "change-quantity"). Where the former ones only have a descriptive
>     purpose ("meaning"), the latter ones are actions for the control
>     flow/application state (which are usually not part of RDF vocabularies
>     now-a-days).
>     It might be better to differentiate them, e.g., via 'rel' (for
>     domain-level semantics) and 'action-rel' (or simply 'action'; for
>     application/protocol-level semantics). Of course, one could also
>     describe them in a vocabulary.
>
>
> The nice thing about the rel attribute is that you can provide multiple
> values if you want.
> <link rel="foobar edit" href="..."/>
>
> If you want to distinguish between "domain" semantics and
> "application/protocol" semantics, you can do that. :-)

Yes, I know and I identified that as a fault/misconception ATM. It's
like putting things together that shouldn't be put together. An action
is not a relation (property, attribute, ...) in that sense.

A triple á la
<#bob> ex:edit <#edit-bob-resource> it not common now-a-days, because it
combines description-level semantics with application-level semantics.
However, it would makes sense to define a new attribute, e.g.,
'action-rel', whose value could be "edit". "edit" could be identified
via a URI, e.g., http://example.com/edit, which could be resolved to
retrieve processing information, e.g., the (HTTP) method, e.g. or the
accept/enc-type to process the referred/target resource. This processing
information could be utilised by the hypermedia client.

The default action in that context could be "view" or "show".

We discussed on the #rest channel at freenode another example (I utilise
your original statements in quotation marks) which includes an
'transclusion link' (LE):

1.  "My client app loads a root resource from a service." - my client
resolved a URI/L
2. "There are a set of available databases that are presented as links
in the root resource." - these are 'navigation links' (LO)
3. "It's a multi-tenant type of app."
4. "One of the links in the root resource is to the user's preferences."
- e.g. <XYZ rel="user-profile"
href="http://example.com/alice-user-profile" />; "user-profile" is a
description-level relation
5. "The client does a LE on the preferences because inside the
preferences, amongst other things is the "preferred" tenant that the
user wishes to use."
6. "So to recap.  The client retrieves the root resource, then GETs  a
LE link, determines the preferred tenant and then does a LO to get to
the "shell" of the tenant."
7. " The difference to me is that the client did not "navigate" to the
preferences end-point.  It merely retrieved that data and aggregated it
into it's current state." - so the client executed an action, e.g.
"retrieve-tenant" to retrieve that piece of information, e.g. <XYZ
rel="user-profile" action-rel="retrieve-tenant"
href="http://example.com/alice-user-profile" />; as described above
"retrieve-tenant" could be resolved to a processing description that
includes e.g. a (SPARQL) query description to retrieve the preferred
tenant of a user for his/her preferences.

Cheers,


Bo

Darrel,

On Jan 10, 2012, at 3:08 PM, Darrel Miller wrote:

> The way I build hypermedia driven clients, it makes a huge difference
> whether a link is an LE or an LO. When I do an LO, my client is
> moving to a new state based on the response from the server. Any
> links that were previously available in the client's previous state
> are potentially no longer valid.

It sounds as if your POV is that the state the client moves to (the next
application state) is somehow known/understood by the server so that the server
would know anything about transitions being valid or not. IOW, that the server
would know anything about the clients application.

Am I reading that correctly?

I'd reply that the application is entirely a concern of the client. The question
of whether a link that the client has seen at some point in time can be used to
construct some successful future request (with the goal of satisfying some
intent) is not part of any application semantics.

In addition I'd reply that the application state is not comprised of only the
response to the previous request but of *all* responses to previous requests
that the client (on 'behalf' of the application being executed) was instructed
to keep track of. If the application is to search trough a number of online
stores to find a certain book and if I keep open 20 windows in my browser, each
displaying a response, then the application state is comprised of all those open
windows.

Makes sense?

Jan


> However, if I do an LE I am simply
> augmenting the clients current state with some additional information.
>
> Consider the scenario where the user-agent is in a state where there
> are two possible LO transitions rel="submit-order"
> rel="change-quantity" and a LE rel="product-details". If I request
> the "product-details" then the client knows that both "submit-order"
> and "change-quantity" are still valid. However, if the client follows
> "submit-order" and the returned response does not include a
> rel="change-quantity" then it would be wise for the client not to
> attempt to try and follow that link.
>
> Darrel
>

Inline

On Wed, Jan 11, 2012 at 12:56 PM, Jan Algermissen
<jan.algermissen@...> wrote:
> Darrel,
>
>
> It sounds as if your POV is that the state the client moves to (the next
application state) is somehow known/understood by the server so that the server
would know anything about transitions being valid or not. IOW, that the server
would know anything about the clients application.
>
> Am I reading that correctly?
>

The state that the client moves to when following a LO is provided by
the server.  So yes, for a brief moment of time the server knows a
significant amount of information about the state the client is moving
to.  I say for a brief moment, because that returned representation
may be created based on information provided in the request that the
server does not hold onto.
The server does not know everything about the client state because,
the client may have accumulated other state during its travels.

> I'd reply that the application is entirely a concern of the client. The
question of whether a link that the client has seen at some point in time can be
used to construct some successful future request (with the goal of satisfying
some intent) is not part of any application semantics.
>
You are correct in that the client has every right to go and dig up an
old link and try and re-use it.  However, it is also in the best
interests of the client to use the information provided to it by the
server to make the smartest decisions.  If a server returns a
representation that does not contain a link that was previously
available,  then it would probably be wise not to present it as an
option to the human.  I tend to use link relations as a way of hinting
to clients which links are safe to hold onto and which ones are not.

> In addition I'd reply that the application state is not comprised of only the
response to the previous request but of *all* responses to previous requests
that the client (on 'behalf' of the application being executed) was instructed
to keep track of. If the application is to search trough a number of online
stores to find a certain book and if I keep open 20 windows in my browser, each
displaying a response, then the application state is comprised of all those open
windows.
>

I would agree that application state can be viewed as an aggregate of
numerous different interactions.  I model that within my client as a
set of independent "agents".  Each open window would have it's own
agent and every agent has the state of the last LO response and and
subsequent LE requests from that LO response.

> Makes sense?
>
It does, but I'm not seeing any contradictions in our opinions.  The
only difference I see is that I tend to view the client as a slave of
the servers it interacts with and other people seem to see it the
other way around.

Darrel

On Jan 11, 2012, at 7:59 PM, Darrel Miller wrote:

> Inline
>
> On Wed, Jan 11, 2012 at 12:56 PM, Jan Algermissen
> <jan.algermissen@...> wrote:
> > Darrel,
> >
> >
> > It sounds as if your POV is that the state the client moves to (the next
application state) is somehow known/understood by the server so that the server
would know anything about transitions being valid or not. IOW, that the server
would know anything about the clients application.
> >
> > Am I reading that correctly?
> >
>
> The state that the client moves to when following a LO is provided by
> the server. So yes, for a brief moment of time the server knows a
> significant amount of information about the state the client is moving
> to. I say for a brief moment, because that returned representation
> may be created based on information provided in the request that the
> server does not hold onto.
> The server does not know everything about the client state because,
> the client may have accumulated other state during its travels.

Yes, I agree.

>
> > I'd reply that the application is entirely a concern of the client. The
question of whether a link that the client has seen at some point in time can be
used to construct some successful future request (with the goal of satisfying
some intent) is not part of any application semantics.
> >
> You are correct in that the client has every right to go and dig up an
> old link and try and re-use it. However, it is also in the best
> interests of the client to use the information provided to it by the
> server to make the smartest decisions. If a server returns a
> representation that does not contain a link that was previously
> available, then it would probably be wise not to present it as an
> option to the human.

Ah, yes - that is a interesting way to express that. Good.

> I tend to use link relations as a way of hinting
> to clients which links are safe to hold onto and which ones are not.

To me, this is the topic of 'bookmarkability' - how does the client know what
links are good to hold on to and which are the ones that are not. Open for
research, IMHO. You seem to think it goes (to some extend) into the link
semantics spec, yes? I think that, too.

>
> > In addition I'd reply that the application state is not comprised of only
the response to the previous request but of *all* responses to previous requests
that the client (on 'behalf' of the application being executed) was instructed
to keep track of. If the application is to search trough a number of online
stores to find a certain book and if I keep open 20 windows in my browser, each
displaying a response, then the application state is comprised of all those open
windows.
> >
>
> I would agree that application state can be viewed as an aggregate of
> numerous different interactions. I model that within my client as a
> set of independent "agents". Each open window would have it's own
> agent and every agent has the state of the last LO response and and
> subsequent LE requests from that LO response.

Ah, ok. I tend to think one agent having many last responses (open windows).
Also interesting to compare the two views.


>
> > Makes sense?
> >
> It does, but I'm not seeing any contradictions in our opinions.

No, did not mean that. I just wanted to make sure you do not think anything
which I'd completely disagree with - otherwise I would get confused, and all :-)

> The
> only difference I see is that I tend to view the client as a slave of
> the servers it interacts with and other people seem to see it the
> other way around.

Ah, right. I view the client as just using the servers as it sees fit (given its
own intended application). OTH, if you define a media type you necessarily are
guided by some perceived 'canonical application' to be achieved with that type
(e.g. create and edit blog entries in the case of AtomPub). And necessarily this
constrains the stuff that the client can do with that media type quite a bit.
And also does the server offer the client hypermedia controls (e.g. links) that
the server things make sense for the client. So the client is also a slave to
the server in what *can* actually happen.

Thanks for clarifying.

Jan

>
> Darrel
>

On Wed, Jan 11, 2012 at 12:13 PM, Jan Algermissen
<jan.algermissen@...> wrote:
> I view the client as just using the servers as it sees fit (given its own
intended application).

This is my view, also.

That probably explains why i have had such a hard time grokking the
perceived difference between embedding and navigation links. From the
client as slave point of view the distinction makes a bit more sense.
Otoh, i have a hard time mapping the client as slave pov onto reality.
:)

Peter
barelyenough.org

> So there's no difference for you between navigational links to other
> resources that require an additional request, and 'embedded' resource state
> that is presented within the representation so that an additional request is
> potentially unnecessary?

That is not what i meant. Clearly there is a difference between
embedding a representation of one resource inside the representation
of another and one representation providing a link to another
resource.

The distinction i have a hard time seeing is the abstract difference
between an `img` and an `link` element (or xinclude vs xlink).
Certainly some clients -- for example browsers -- treat those link
flavors very differently, but to me that seems like an implementation
detail of the client. Others seem to view the distinction as more
important.

Peter
barelyenough.org

On Wed, Jan 11, 2012 at 8:02 PM, Peter Williams <pezra@...> wrote:
>
>
>
> > So there's no difference for you between navigational links to other
> > resources that require an additional request, and 'embedded' resource state
> > that is presented within the representation so that an additional request is
> > potentially unnecessary?
>
> That is not what i meant. Clearly there is a difference between
> embedding a representation of one resource inside the representation
> of another and one representation providing a link to another
> resource.
>

Ok. fwiw, that also falls under 'embed link' in mike's H Factors -
hence the question.

>
> The distinction i have a hard time seeing is the abstract difference
> between an `img` and an `link` element (or xinclude vs xlink).
> Certainly some clients -- for example browsers -- treat those link
> flavors very differently, but to me that seems like an implementation
> detail of the client. Others seem to view the distinction as more
> important.
>


wrt HTML's img tag - it's explicit about the embed semantics:

"The IMG element embeds an image in the current document at the
location of the element's definition. The IMG element has no content;
it is usually replaced inline by the image designated by the src
attribute.."

Cheers,
Mike

> wrt HTML's img tag - it's explicit about the embed semantics:

True, and yet many clients completely ignore that bit of the spec and
treat it as a navigational link.

Peter
barelyenough.org

On Wed, Jan 11, 2012 at 1:44 PM, Darrel Miller <darrel.miller@...> wrote:
> In this
>
post  http://old.nabble.com/Re%3A-Unifying---standardizing-X-Moz---X-Purpose-hea\
ders-p29794338.html Roy
> talks about the notion of passive links in Waka.  Without putting works into
> Roy's mouth, this is what I consider to be a LE.

The way i read that post, message type is a way for the client to
inform the server how it has decided to use a particular link. Not a
way for the server to tell the client how it should use a particular
link. Ie, it would be ok for a client to dereference a `img` tag link
as an active request (or any other valid value, for that matter).

Peter
barelyenough.org