Hi Markus,

Is it fair to say that any media type that supports exposing links
with custom relation types satisfies this requirement, since custom
relation types can specify non-safe semantics of a link?

Cheers,
Mike

On Tue, Jan 17, 2012 at 2:10 PM, Markus Lanthaler
<markus.lanthaler@...> wrote:
> Hi Mike,
>
> No it’s the other way round.. I’m looking for formats (media types) which
> support describing links that can also use other HTTP methods than HTTP GET.
>
> Cheers,
>
> Markus
>
> From: Mike Kelly [mailto:mikekelly321@...]
> Sent: Tuesday, January 17, 2012 9:36 PM
> To: Markus Lanthaler
> Cc: REST-Discuss Discussion Group
> Subject: Re: [rest-discuss] Formats with native hypermedia support
>
> Hi Markus,
>
> By "beyond just links supporting a GET", is the implication that links
> cannot/should not drive non-safe interactions such as POST/PUT/DELETE ?
>
> Cheers,
>
> Mike
>

Hmm.. I'm not sure.. perhaps creating a seconds list of formats supporting
user defined link semantics would be interesting as well. I wouldn't like to
mix them.

Some falling into this category that quickly came to my mind:
- HTML
- Atom
- HAL
- RDF/XML, Turtle, N3, ...
- JSON-LD
- WADL/WSDL??


--
Markus Lanthaler
@markuslanthaler




> -----Original Message-----
> From: rest-discuss@yahoogroups.com [mailto:rest-
> discuss@yahoogroups.com] On Behalf Of Mike Kelly
> Sent: Tuesday, January 17, 2012 10:26 PM
> To: Markus Lanthaler
> Cc: REST-Discuss Discussion Group
> Subject: Re: [rest-discuss] Formats with native hypermedia support
>
> Hi Markus,
>
> Is it fair to say that any media type that supports exposing links
> with custom relation types satisfies this requirement, since custom
> relation types can specify non-safe semantics of a link?
>
> Cheers,
> Mike
>
> On Tue, Jan 17, 2012 at 2:10 PM, Markus Lanthaler
> <markus.lanthaler@...> wrote:
> > Hi Mike,
> >
> > No it’s the other way round.. I’m looking for formats (media types)
> which
> > support describing links that can also use other HTTP methods than
> HTTP GET.
> >
> > Cheers,
> >
> > Markus
> >
> > From: Mike Kelly [mailto:mikekelly321@...]
> > Sent: Tuesday, January 17, 2012 9:36 PM
> > To: Markus Lanthaler
> > Cc: REST-Discuss Discussion Group
> > Subject: Re: [rest-discuss] Formats with native hypermedia support
> >
> > Hi Markus,
> >
> > By "beyond just links supporting a GET", is the implication that
> links
> > cannot/should not drive non-safe interactions such as POST/PUT/DELETE
> ?
> >
> > Cheers,
> >
> > Mike
> >
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Hi Markus,

I would propose to correct the list as following:

- HTML
- Atom & AtumPub
- Collection+JSON
- HAL

Cheers,


Bo


PS: especially, all existing RDF serialisation forms support natively
only LO (in my mind)


On 1/17/2012 3:46 PM, Markus Lanthaler wrote:
> Hmm.. I'm not sure.. perhaps creating a seconds list of formats supporting
> user defined link semantics would be interesting as well. I wouldn't like to
> mix them.
>
> Some falling into this category that quickly came to my mind:
> - HTML
> - Atom
> - HAL
> - RDF/XML, Turtle, N3, ...
> - JSON-LD
> - WADL/WSDL??
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>  > -----Original Message-----
>  > From: rest-discuss@yahoogroups.com
> <mailto:rest-discuss%40yahoogroups.com> [mailto:rest-
>  > discuss@yahoogroups.com <mailto:discuss%40yahoogroups.com>] On Behalf
> Of Mike Kelly
>  > Sent: Tuesday, January 17, 2012 10:26 PM
>  > To: Markus Lanthaler
>  > Cc: REST-Discuss Discussion Group
>  > Subject: Re: [rest-discuss] Formats with native hypermedia support
>  >
>  > Hi Markus,
>  >
>  > Is it fair to say that any media type that supports exposing links
>  > with custom relation types satisfies this requirement, since custom
>  > relation types can specify non-safe semantics of a link?
>  >
>  > Cheers,
>  > Mike
>  >
>  > On Tue, Jan 17, 2012 at 2:10 PM, Markus Lanthaler
>  > <markus.lanthaler@... <mailto:markus.lanthaler%40gmx.net>> wrote:
>  > > Hi Mike,
>  > >
>  > > No it’s the other way round.. I’m looking for formats (media types)
>  > which
>  > > support describing links that can also use other HTTP methods than
>  > HTTP GET.
>  > >
>  > > Cheers,
>  > >
>  > > Markus
>  > >
>  > > From: Mike Kelly [mailto:mikekelly321@...
> <mailto:mikekelly321%40gmail.com>]
>  > > Sent: Tuesday, January 17, 2012 9:36 PM
>  > > To: Markus Lanthaler
>  > > Cc: REST-Discuss Discussion Group
>  > > Subject: Re: [rest-discuss] Formats with native hypermedia support
>  > >
>  > > Hi Markus,
>  > >
>  > > By "beyond just links supporting a GET", is the implication that
>  > links
>  > > cannot/should not drive non-safe interactions such as POST/PUT/DELETE
>  > ?
>  > >
>  > > Cheers,
>  > >
>  > > Mike

On Tue, Jan 17, 2012 at 7:53 AM, Bob Ferris <zazi@...> wrote:
> PS: especially, all existing RDF serialisation forms support natively
> only LO (in my mind)

It is worth noting that some of us do not believe that the LO vs LE
distinction is an important one at the media type level. It seems to
me purely a request time distinction.

Peter
barelyenough.org

> I would propose to correct the list as following:

Which list was wrong in your opinion? Currently I have the following two:

Native hypermedia support beyond GET:
- HTML (GET/POST/PUT)
- Atom+AtomPub (GET/POST/PUT/DELETE)
- WSDL (GET/POST/PUT/DELETE)
- WADL (GET/POST/PUT/HEAD/DELETE)
- Collection+JSON (GET/POST/PUT/DELETE)
- CCXML (GET/POST) - thanks to Erlend
- Shoji (GET/POST/PUT/DELETE) - thanks to Robert

Allow "semantic" annotation of links which can be used to support other
methods
- HTML
- Atom+AtomPub
- HAL
- RDF/XML, Turtle, N3, ...
- JSON-LD
- WADL/WSDL??



--
Markus Lanthaler
@markuslanthaler




> -----Original Message-----
> From: rest-discuss@yahoogroups.com [mailto:rest-
> discuss@yahoogroups.com] On Behalf Of Bob Ferris
> Sent: Tuesday, January 17, 2012 10:53 PM
> Cc: 'REST-Discuss Discussion Group'
> Subject: Re: [rest-discuss] Formats with native hypermedia support
>
> Hi Markus,
>
> I would propose to correct the list as following:
>
> - HTML
> - Atom & AtumPub
> - Collection+JSON
> - HAL
>
> Cheers,
>
>
> Bo
>
>
> PS: especially, all existing RDF serialisation forms support natively
> only LO (in my mind)
>
>
> On 1/17/2012 3:46 PM, Markus Lanthaler wrote:
> > Hmm.. I'm not sure.. perhaps creating a seconds list of formats
> supporting
> > user defined link semantics would be interesting as well. I wouldn't
> like to
> > mix them.
> >
> > Some falling into this category that quickly came to my mind:
> > - HTML
> > - Atom
> > - HAL
> > - RDF/XML, Turtle, N3, ...
> > - JSON-LD
> > - WADL/WSDL??
> >
> > --
> > Markus Lanthaler
> > @markuslanthaler
> >
> >  > -----Original Message-----
> >  > From: rest-discuss@yahoogroups.com
> > <mailto:rest-discuss%40yahoogroups.com> [mailto:rest-
> >  > discuss@yahoogroups.com <mailto:discuss%40yahoogroups.com>] On
> Behalf
> > Of Mike Kelly
> >  > Sent: Tuesday, January 17, 2012 10:26 PM
> >  > To: Markus Lanthaler
> >  > Cc: REST-Discuss Discussion Group
> >  > Subject: Re: [rest-discuss] Formats with native hypermedia support
> >  >
> >  > Hi Markus,
> >  >
> >  > Is it fair to say that any media type that supports exposing links
> >  > with custom relation types satisfies this requirement, since
> custom
> >  > relation types can specify non-safe semantics of a link?
> >  >
> >  > Cheers,
> >  > Mike
> >  >
> >  > On Tue, Jan 17, 2012 at 2:10 PM, Markus Lanthaler
> >  > <markus.lanthaler@... <mailto:markus.lanthaler%40gmx.net>>
> wrote:
> >  > > Hi Mike,
> >  > >
> >  > > No it's the other way round.. I'm looking for formats (media
> types)
> >  > which
> >  > > support describing links that can also use other HTTP methods
> than
> >  > HTTP GET.
> >  > >
> >  > > Cheers,
> >  > >
> >  > > Markus
> >  > >
> >  > > From: Mike Kelly [mailto:mikekelly321@...
> > <mailto:mikekelly321%40gmail.com>]
> >  > > Sent: Tuesday, January 17, 2012 9:36 PM
> >  > > To: Markus Lanthaler
> >  > > Cc: REST-Discuss Discussion Group
> >  > > Subject: Re: [rest-discuss] Formats with native hypermedia
> support
> >  > >
> >  > > Hi Markus,
> >  > >
> >  > > By "beyond just links supporting a GET", is the implication that
> >  > links
> >  > > cannot/should not drive non-safe interactions such as
> POST/PUT/DELETE
> >  > ?
> >  > >
> >  > > Cheers,
> >  > >
> >  > > Mike
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Markus,

as you've already mentioned in another post in this thread:

"The subject of this thread is "formats with native hypermedia support
going beyond GET""

So my list (see below) was about this topic ;)

Cheers,


Bo


On 1/17/2012 5:23 PM, Markus Lanthaler wrote:
>> I would propose to correct the list as following:
>
> Which list was wrong in your opinion? Currently I have the following two:
>
> Native hypermedia support beyond GET:
> - HTML (GET/POST/PUT)
> - Atom+AtomPub (GET/POST/PUT/DELETE)
> - WSDL (GET/POST/PUT/DELETE)
> - WADL (GET/POST/PUT/HEAD/DELETE)
> - Collection+JSON (GET/POST/PUT/DELETE)
> - CCXML (GET/POST) - thanks to Erlend
> - Shoji (GET/POST/PUT/DELETE) - thanks to Robert
>
> Allow "semantic" annotation of links which can be used to support other
> methods
> - HTML
> - Atom+AtomPub
> - HAL
> - RDF/XML, Turtle, N3, ...
> - JSON-LD
> - WADL/WSDL??
>
>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>
>
>
>> -----Original Message-----
>> From: rest-discuss@yahoogroups.com [mailto:rest-
>> discuss@yahoogroups.com] On Behalf Of Bob Ferris
>> Sent: Tuesday, January 17, 2012 10:53 PM
>> Cc: 'REST-Discuss Discussion Group'
>> Subject: Re: [rest-discuss] Formats with native hypermedia support
>>
>> Hi Markus,
>>
>> I would propose to correct the list as following:
>>
>> - HTML
>> - Atom&  AtumPub
>> - Collection+JSON
>> - HAL
>>
>> Cheers,
>>
>>
>> Bo

Shoji [1] has POST/PUT/DELETE support very similar to AtomPub.


Robert Brewer
fumanchu@...

[1] www.aminus.org/rbre/shoji/shoji-draft-02.txt

> -----Original Message-----
> From: rest-discuss@yahoogroups.com [mailto:rest-
> discuss@yahoogroups.com] On Behalf Of Markus Lanthaler
> Sent: Tuesday, January 17, 2012 5:24 AM
> To: 'REST-Discuss Discussion Group'
> Subject: [rest-discuss] Formats with native hypermedia support
>
> Hi,
>
> I'm trying to create a list of formats with native hypermedia support
> (HTTP)
> that goes beyond just links supporting a GET.. So far my list is quite
> short
> and I can't believe that that's all:
>
> - HTML (GET/POST/PUT)
> - Atom & AtomPub (GET/POST/PUT/DELETE)
> - WSDL (GET/POST/PUT/DELETE)
> - WADL (GET/POST/PUT/HEAD/DELETE)
> - Collection+JSON (GET/POST/PUT/DELETE)
>
>
> I'm sure I missed a lot. Do you know of any other formats?
>
>
> Thanks,
> Markus
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

The problem with separating them into groups this way is that there is
so much grey area.. e.g. you have included Atom which effectively
drives its non-safe requests with generic links and specific relation
types - what is the distinction there?

Fwiw, I usually analyse media types using mamund's H Factors, or a set
of terminology very similar to it. Are they not sufficient for your
case?

Cheers,
Mike

On Tue, Jan 17, 2012 at 2:46 PM, Markus Lanthaler
<markus.lanthaler@...> wrote:
> Hmm.. I'm not sure.. perhaps creating a seconds list of formats supporting
> user defined link semantics would be interesting as well. I wouldn't like to
> mix them.
>
> Some falling into this category that quickly came to my mind:
> - HTML
> - Atom
> - HAL
> - RDF/XML, Turtle, N3, ...
> - JSON-LD
> - WADL/WSDL??
>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>
>
>
>> -----Original Message-----
>> From: rest-discuss@yahoogroups.com [mailto:rest-
>> discuss@yahoogroups.com] On Behalf Of Mike Kelly
>> Sent: Tuesday, January 17, 2012 10:26 PM
>> To: Markus Lanthaler
>> Cc: REST-Discuss Discussion Group
>> Subject: Re: [rest-discuss] Formats with native hypermedia support
>>
>> Hi Markus,
>>
>> Is it fair to say that any media type that supports exposing links
>> with custom relation types satisfies this requirement, since custom
>> relation types can specify non-safe semantics of a link?
>>
>> Cheers,
>> Mike
>>
>> On Tue, Jan 17, 2012 at 2:10 PM, Markus Lanthaler
>> <markus.lanthaler@...> wrote:
>> > Hi Mike,
>> >
>> > No it’s the other way round.. I’m looking for formats (media types)
>> which
>> > support describing links that can also use other HTTP methods than
>> HTTP GET.
>> >
>> > Cheers,
>> >
>> > Markus
>> >
>> > From: Mike Kelly [mailto:mikekelly321@...]
>> > Sent: Tuesday, January 17, 2012 9:36 PM
>> > To: Markus Lanthaler
>> > Cc: REST-Discuss Discussion Group
>> > Subject: Re: [rest-discuss] Formats with native hypermedia support
>> >
>> > Hi Markus,
>> >
>> > By "beyond just links supporting a GET", is the implication that
>> links
>> > cannot/should not drive non-safe interactions such as POST/PUT/DELETE
>> ?
>> >
>> > Cheers,
>> >
>> > Mike
>> >
>>
>>
>> ------------------------------------
>>
>> Yahoo! Groups Links
>>
>>
>>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

The distinction I make is more whether the spec specifies those semantics
(as Atom does e.g.) or whether those are application specific semantics such
as in any form of RDF.


Cheers,
Markus




> -----Original Message-----
> From: rest-discuss@yahoogroups.com [mailto:rest-
> discuss@yahoogroups.com] On Behalf Of Mike Kelly
> Sent: Tuesday, January 17, 2012 11:00 PM
> To: Markus Lanthaler
> Cc: REST-Discuss Discussion Group
> Subject: Re: [rest-discuss] Formats with native hypermedia support
>
> The problem with separating them into groups this way is that there is
> so much grey area.. e.g. you have included Atom which effectively
> drives its non-safe requests with generic links and specific relation
> types - what is the distinction there?
>
> Fwiw, I usually analyse media types using mamund's H Factors, or a set
> of terminology very similar to it. Are they not sufficient for your
> case?
>
> Cheers,
> Mike

On Tue, Jan 17, 2012 at 9:17 AM, Markus Lanthaler
<markus.lanthaler@...> wrote:
> The distinction I make is more whether the spec specifies those semantics
> (as Atom does e.g.) or whether those are application specific semantics such
> as in any form of RDF.

I don't think any media type provides exactly those semantics. What
they provide is higher level application level semantics, eg "the
resource at this uri is an image that the user will often want to see
embedded in the document". However, clients are *not* obliged to treat
that link as embedded. A client might fetch that resource
automatically and embed it (gui browsers), they might fetch that
resource automatically and not embed it (caching proxies), they might
render it as a clickable link (a text based browser), or they might
just ignore it entirely (most automated user agents).

Clients have exactly the same set of choices for what to do with a
link regardless of whether it is an `<link>`, `<img>` or `<a>` tag.
They consider the application semantics of the link for their use case
and decide whether to treat linked resources a something to embed or
not.

I don't think RDF serializations are any different. Clients consider
the semantics of the relationships of the links for their use case and
decide whether or not to embed the linked resources.

Peter
barelyenough.org

Peter:

<snip>
However, clients are *not* obliged to treat that link as embedded.
</snip>

First, i agree.

Second, in the converse, can you tell me what it is that appears in a
media type message design that clients *are* obliged to do (or, to use
your phrase "obliged to treat as...", etc.)?

Finally, the work i did on H-Factors was not meant as a set of
"obligations" for either client or server.

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




On Tue, Jan 17, 2012 at 12:06, Peter Williams <pezra@...> wrote:
> On Tue, Jan 17, 2012 at 9:17 AM, Markus Lanthaler
> <markus.lanthaler@...> wrote:
>> The distinction I make is more whether the spec specifies those semantics
>> (as Atom does e.g.) or whether those are application specific semantics such
>> as in any form of RDF.
>
> I don't think any media type provides exactly those semantics. What
> they provide is higher level application level semantics, eg "the
> resource at this uri is an image that the user will often want to see
> embedded in the document". However, clients are *not* obliged to treat
> that link as embedded. A client might fetch that resource
> automatically and embed it (gui browsers), they might fetch that
> resource automatically and not embed it (caching proxies), they might
> render it as a clickable link (a text based browser), or they might
> just ignore it entirely (most automated user agents).
>
> Clients have exactly the same set of choices for what to do with a
> link regardless of whether it is an `<link>`, `<img>` or `<a>` tag.
> They consider the application semantics of the link for their use case
> and decide whether to treat linked resources a something to embed or
> not.
>
> I don't think RDF serializations are any different. Clients consider
> the semantics of the relationships of the links for their use case and
> decide whether or not to embed the linked resources.
>
> Peter
> barelyenough.org
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

On Tue, Jan 17, 2012 at 6:20 PM, mike amundsen <mamund@...> wrote:
> Peter:
>
> <snip>
> However, clients are *not* obliged to treat that link as embedded.
> </snip>
>
> First, i agree.
>
> Second, in the converse, can you tell me what it is that appears in a
> media type message design that clients *are* obliged to do (or, to use
> your phrase "obliged to treat as...", etc.)?

I don't think there is anything. I am trying to gain an understanding
of common perception that there are two kinds of links (LE and LO). It
seems to me that any link could be either in some contexts. If that is
true then using that to categorize media type seems flawed.

> Finally, the work i did on H-Factors was not meant as a set of
> "obligations" for either client or server.

Of course not, i never thought it was. Its just that the link support
categorizations are based on a conceptual model of media types and
REST that i do not (yet?) share.

Peter
barelyenough.org

Peter:

i appreciate your reply.

so, we both agree that the H-Factors are not to be interpreted as
"obligations." we also both agree that we cannot think of anything
that appears within a media type design that should be interpreted as
an obligation.

so, my next question is to ask, using HTML as an _example_ (since
there are other media type designs that provide the same types of
elements):

"how would *you* then describe, characterize, etc. the elements
HTML.IMG and HTML.A and how would *you* differentiate the two?

for example, in identifying H-Factors, i choose to characterize them
both as "link" elements. i choose to differentiate them based on the
"shared understanding" (as defined in the HTML spec) that one
indicates a transclusion and the other indicates a navigation.

note that the criteria i have adopted here are not tied to any
architectural style (i.e. REST, RPC, EBI, etc.). instead, i am
characterizing these elements based on what they *afford* the
recipient of the representation. note also, i am not placing a *value*
or *correctness* assessment on these affordances (i.e. "transclusion
is only valid in use case X" or "there is no need for anything other
than navigation links in all use cases", etc.).

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




On Wed, Jan 18, 2012 at 09:32, Peter Williams <pezra@...> wrote:
> On Tue, Jan 17, 2012 at 6:20 PM, mike amundsen <mamund@...> wrote:
>> Peter:
>>
>> <snip>
>> However, clients are *not* obliged to treat that link as embedded.
>> </snip>
>>
>> First, i agree.
>>
>> Second, in the converse, can you tell me what it is that appears in a
>> media type message design that clients *are* obliged to do (or, to use
>> your phrase "obliged to treat as...", etc.)?
>
> I don't think there is anything. I am trying to gain an understanding
> of common perception that there are two kinds of links (LE and LO). It
> seems to me that any link could be either in some contexts. If that is
> true then using that to categorize media type seems flawed.
>
>> Finally, the work i did on H-Factors was not meant as a set of
>> "obligations" for either client or server.
>
> Of course not, i never thought it was. Its just that the link support
> categorizations are based on a conceptual model of media types and
> REST that i do not (yet?) share.
>
> Peter
> barelyenough.org
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

On Wed, Jan 18, 2012 at 10:02 AM, mike amundsen <mamund@...> wrote:
> "how would *you* then describe, characterize, etc. the elements
> HTML.IMG and HTML.A and how would *you* differentiate the two?

I would just say they are both links. They do have different document
layout semantics that are useful for visually presenting HTML encoded
documents. That does not imply to me that i should expect/look for
similar semantics in media types for other domains.

> for example, in identifying H-Factors, i choose to characterize them
> both as "link" elements. i choose to differentiate them based on the
> "shared understanding" (as defined in the HTML spec) that one
> indicates a transclusion and the other indicates a navigation.

To my mind that shared understanding is domain specific, rather than
an affordance that would necessarily be available in any other
context. Fundamentally, HTML provides a way to describe (graphical)
user interfaces. In that context there is a significant difference
between transclusion and navigation. In other visually oriented
domains i would also expect a significant differences between
transclusion and linking out. However, i find the distinction less
compelling once you move to describing domains (read: media types)
that are less visually oriented.

By analogy, i think categorizing media types by whether they have LE
affordances is a bit like categorizing all physical objects by whether
they have a feature that affords pulling. In some contexts (doors)
such a categorization can be useful, in others it is clearly not. So
while you certainly could ask the question "does this object have a
feature that affords pulling" for any physical object it is probably
not a very important way to segment the set of all physical objects.

Asking that question has negative impacts, though. It encourages
people to unnecessarily put pull handles on the sides of houses just
so they can check that box. It make some wonder if they have missed
something really important because the desk they just designed doesn't
have pull handle. It also causes them to get into long mailing list
discussions about whether the hitch on their trailer counts as pull
handle or not. ;)

Peter
barelyenough.org

On Wed, Jan 18, 2012 at 14:34, Peter Williams <pezra@...> wrote:
> On Wed, Jan 18, 2012 at 10:02 AM, mike amundsen <mamund@...> wrote:
>> "how would *you* then describe, characterize, etc. the elements
>> HTML.IMG and HTML.A and how would *you* differentiate the two?
>
> I would just say they are both links. They do have different document
> layout semantics that are useful for visually presenting HTML encoded
> documents.

You're playing w/ me, right?

> That does not imply to me that i should expect/look for
> similar semantics in media types for other domains.

no, it does not imply that you should expect/look, etc. where is this coming
from?

>> for example, in identifying H-Factors, i choose to characterize them
>> both as "link" elements. i choose to differentiate them based on the
>> "shared understanding" (as defined in the HTML spec) that one
>> indicates a transclusion and the other indicates a navigation.
>
> To my mind that shared understanding is domain specific, rather than
> an affordance that would necessarily be available in any other
> context.

so is this whole discussion about you telling me i have my "scoping" wrong?

> i find the distinction less
> compelling once you move to describing domains (read: media types)
> that are less visually oriented.

so, you think transclusion is only "compelling" if the output is visual, right?
and "compelling" is your term for measure?

>
> Peter
> barelyenough.org

On Wed, Jan 18, 2012 at 1:48 PM, mike amundsen <mamund@...> wrote:
>> That does not imply to me that i should expect/look for
>> similar semantics in media types for other domains.
>
> no, it does not imply that you should expect/look, etc. where is this coming
from?

You list LE as one of the hypermedia factors. That implied to me that
you look for it (even if you don't necessarily expect it) in other
media types.

Until this conversation i was under the, apparently false, assumption
that the h-factors list was a collect them all sort of thing. The more
h-factors a media type has the better it is. The first line of the
page certainly seems to imply this, "The H Factor of a media-type is a
measurement of the level of hypermedia support and sophistication of a
media-type."

> so is this whole discussion about you telling me i have my "scoping" wrong?

I don't know, maybe. It is hard for me to tell for sure. Maybe i am
missing something really fundamental.

>> i find the distinction less
>> compelling once you move to describing domains (read: media types)
>> that are less visually oriented.
>
> so, you think transclusion is only "compelling" if the output is visual,
right?

I do find embedding graphical elements in documents and user
interfaces (certainly a form a transclusion) compelling. However,
there are many other contexts in which various forms of transclusion
are useful (and therefore compelling. I used the embedded image
example because we have been using HTML as an example.

> and "compelling" is your term for measure?

Not exactly. A measure of hypermedia capability is compelling to me if
i think it would be reasonable and useful to ask the question of any
media type, regardless of domain.  For example, i find LT to be an
extremely compelling measure to consider when evaluating, comparing
and designing media types.

I think my concern comes down to the fact that i just don't see the
similarity between `<img src="..."/>` and `<link rel="stylesheet"
href="...">` (i assume this is considered an LE link) other than they
are often dereferenced automatically.

Hmm... does LE mean "the media type contains a flavor of link which
will be automatically dereferenced by the canonical consumer"?

Peter
barelyenough.org

On Wed, Jan 18, 2012 at 17:08, Peter Williams <pezra@...> wrote:
> On Wed, Jan 18, 2012 at 1:48 PM, mike amundsen <mamund@...> wrote:
>>> That does not imply to me that i should expect/look for
>>> similar semantics in media types for other domains.
>>
>> no, it does not imply that you should expect/look, etc. where is this coming
from?
>
> You list LE as one of the hypermedia factors. That implied to me that
> you look for it (even if you don't necessarily expect it) in other
> media types.

ok, yes. i *do* find them in other designs and _use_ them in my own
new designs. i guess i got hung up on "should" and "expect" in a way
you didn't mean. sure, these appear other places (transclusion,
navigation, URI templating, payload templating, non/idempotent
requests, protocol method selection, request header manipulation,
tokenizing of link actions, etc. while HTML offers common examples of
most of all of these, Atom, VoiceXML, URI-List, HAL, Collection-JSON,
etc. all show examples, too.

>
> Until this conversation i was under the, apparently false, assumption
> that the h-factors list was a collect them all sort of thing. The more
> h-factors a media type has the better it is. The first line of the
> page certainly seems to imply this, "The H Factor of a media-type is a
> measurement of the level of hypermedia support and sophistication of a
> media-type."

yep, that text about "sophisitication" is pretty weak, eh? i wrote it
early in my experiments and should really update the page, relegate
some text to archives, etc.

the list i present there is not meant to be definitive (all
inclusive). i'm open to new ideas on how to improve it; both at the
membership and the narrative levels. and the idea was definitely *not*
to create a hierarchy with which to judge designs. just as creating a
set of constraints (color, materials, processing) for any industrial
design can add structure and cohesion, the factor model was meant as
an aide in design and analysis, not as a measure of judgement.

>
>> so is this whole discussion about you telling me i have my "scoping" wrong?
>
> I don't know, maybe. It is hard for me to tell for sure. Maybe i am
> missing something really fundamental.

well, i suspect the two of us are not yet on the same wave-length for
general terms. the last few posts have helped to teach me more about
your POV and i suspect it will take more typing still, that's all.

>
>>> i find the distinction less
>>> compelling once you move to describing domains (read: media types)
>>> that are less visually oriented.
>>
>> so, you think transclusion is only "compelling" if the output is visual,
right?
>
> I do find embedding graphical elements in documents and user
> interfaces (certainly a form a transclusion) compelling. However,
> there are many other contexts in which various forms of transclusion
> are useful (and therefore compelling. I used the embedded image
> example because we have been using HTML as an example.

yeah, my point here is that compelling or not, these things exist. i
have decided to *not* attempt to say one or more of these things
SHOULD or MUST only be used in certain cases (visual rendering only,
etc.). i have treated all the factors this way. for example, i do not
say HTML is inferior because it does not offer support for idempotent
actions. i do not say that Atom is flawed because it offers no native
affordance for templated queries, etc. so "compelling" didn't enter
into my decision on what is included in the H-Factor list.

>
>> and "compelling" is your term for measure?
>
> Not exactly. A measure of hypermedia capability is compelling to me if
> i think it would be reasonable and useful to ask the question of any
> media type, regardless of domain.  For example, i find LT to be an
> extremely compelling measure to consider when evaluating, comparing
> and designing media types.

compelling -> reasonable -> useful  it's good stuff, but not the kind
of measures i used when creating the list.

sure, you can create a media type design that uses _all_ these, just
one of these, etc. you can even create a really _ugly_, _unhelpful_
design with them!  my point is to document what's here and talk about
how they are used today.

so, yes, talking about how useful -> reasonable, etc. some of the
affordances are in some cases at some period of time for some apps,
etc. is great. that switches from talking about whether an item ought
to be on my H-Factor *list* to whether an item on my H-Factor list
ought to be in a particular *design*; very worthwhile stuff. and much
of that talk will use words like "compelling", "useful",
"appriopriate", "successful', etc. because that's how design
implementations are evaluated.

but if the talk is to be about whether an item should be on the
H-Factor list at all, then i think the way we talk about these
affordances is different; the measures are different, the
examples/evidence are different. do transclusion affordances exists in
some designs? if so, should this affordance be included in the list of
possible factors? if yes, why; if not, why?, etc.

> Hmm... does LE mean "the media type contains a flavor of link which
> will be automatically dereferenced by the canonical consumer"?

that's an interesting observation. i have not included details on
_how_ these affordances must be treated by clients; only that they
appear and have a shared understanding between client and server.
immediate, deferred, pre-fetched, etc. are not included in my
affordance criteria right now and i do not know of any media type
documentation that defines in-message affordances as having these
constraints.

On Wed, Jan 18, 2012 at 3:53 PM, mike amundsen <mamund@...> wrote:

> yeah, my point here is that [...] these things exist.

So does block quoting, but i don't use that as a way categorization
media types.

My point here is that some ways of categorizing are more useful than
others. I see "embedded" vs "navigation" distinction as less useful.
(And largely completely indistinguishable in m2m scenarios.)

I think my strong reaction was partly due to an misunderstanding of
what you mean by LE and how you use the h-factors technique. If
h-factors were usually treated as a set of categorizations any of
which might or might not be useful in the situation at hand (which i
am beginning to infer is how you use them) then i would have no
concerns. However, most of the discussions involving the h-factors of
media types do *not* have that flavor to me.

Peter
barelyenough.org

On Thu, Jan 19, 2012 at 14:30, Peter Williams <pezra@...> wrote:
> On Wed, Jan 18, 2012 at 3:53 PM, mike amundsen <mamund@...> wrote:
>
>> yeah, my point here is that [...] these things exist.
>
> So does block quoting, but i don't use that as a way categorization
> media types.
Ouch!

>
> My point here is that some ways of categorizing are more useful than
> others. I see "embedded" vs "navigation" distinction as less useful.
> (And largely completely indistinguishable in m2m scenarios.)
>
> I think my strong reaction was partly due to an misunderstanding of
> what you mean by LE and how you use the h-factors technique. If
> h-factors were usually treated as a set of categorizations any of
> which might or might not be useful in the situation at hand (which i
> am beginning to infer is how you use them) then i would have no
> concerns. However, most of the discussions involving the h-factors of
> media types do *not* have that flavor to me.

hopefully your perception of my intent is a bit clearer now, possibly a bit more
positive, too (if i'm lucky).


>
> Peter
> barelyenough.org

> hopefully your perception of my intent is a bit clearer now, possibly a bit
more positive, too (if i'm lucky).

My perception of your intent is, and always has been, entirely
positive. I appreciate you taking the time to talk though this with
me.

Peter
barelyenough.org

Wednesday, January 18, 2012 1:06 AM, Peter Williams wrote:
> On Tue, Jan 17, 2012 at 9:17 AM, Markus Lanthaler wrote:
> > The distinction I make is more whether the spec specifies those
> > semantics (as Atom does e.g.) or whether those are application
> > specific semantics such as in any form of RDF.
>
> I don't think any media type provides exactly those semantics. What
> they provide is higher level application level semantics, eg "the
> resource at this uri is an image that the user will often want to see
> embedded in the document".

I was not talking about LE or LO. I was talking about HTTP methods. AtomPub,
e.g., clearly specifies that how member URIs with a link relation of "edit"
should be used.

"The Member URI allows clients to retrieve, edit, and delete a Member
Resource using HTTP's GET, PUT, and DELETE methods."

and

"A Member Entry SHOULD contain such an atom:link element with a link
relation of "edit", which indicates the Member URI."


> Clients have exactly the same set of choices for what to do with a
> link regardless of whether it is an `<link>`, `<img>` or `<a>` tag.
> They consider the application semantics of the link for their use case
> and decide whether to treat linked resources a something to embed or
> not.

Would you say the same is true for form@method="get" and form@method="post"?
I don't think any client out there will issue a GET when a POST is defined
or the other way round.. The same applies for a a@rel="edit" link in an Atom
document.

The issue you described above is another aspect which is irrelevant in this
context.


> I don't think RDF serializations are any different. Clients consider
> the semantics of the relationships of the links for their use case and
> decide whether or not to embed the linked resources.

... but RDF doesn't describe any of them - in contrast to Atom's "edit"
relation e.g.



--
Markus Lanthaler
@markuslanthaler

On Tue, Jan 17, 2012 at 7:30 PM, Markus Lanthaler
<markus.lanthaler@...> wrote:
> Wednesday, January 18, 2012 1:06 AM, Peter Williams wrote:
>> On Tue, Jan 17, 2012 at 9:17 AM, Markus Lanthaler wrote:
>> > The distinction I make is more whether the spec specifies those
>> > semantics (as Atom does e.g.) or whether those are application
>> > specific semantics such as in any form of RDF.
>>
>> I don't think any media type provides exactly those semantics. What
>> they provide is higher level application level semantics, eg "the
>> resource at this uri is an image that the user will often want to see
>> embedded in the document".
>
> I was not talking about LE or LO.

Ah. I misunderstood, sorry.

> I was talking about HTTP methods. AtomPub,
> e.g., clearly specifies that how member URIs with a link relation of "edit"
> should be used.

How is `<link rel="edit" ...` in an Atom document different than a
property `http://example.com/vocab/modify-by-putting-here` that points
to the "member" resource in RDF?

>> Clients have exactly the same set of choices for what to do with a
>> link regardless of whether it is an `<link>`, `<img>` or `<a>` tag.
>> They consider the application semantics of the link for their use case
>> and decide whether to treat linked resources a something to embed or
>> not.
>
> Would you say the same is true for form@method="get" and form@method="post"?
> I don't think any client out there will issue a GET when a POST is defined
> or the other way round.. The same applies for a a@rel="edit" link in an Atom
> document.

I don't think (m)any clients would try to get the resource from a POST
form.  However, they are welcome to if they want. That is part of the
uniform interface. Every resource responses to every method.

A client is also allowed to GET every permutation of a get form
without any user input, not that it is usually a good idea.

Peter

On Wednesday, January 18, 2012 11:00 PM, Peter Williams wrote:
> > [...]
> > I was not talking about LE or LO.
>
> Ah. I misunderstood, sorry.
>
> > I was talking about HTTP methods. AtomPub,
> > e.g., clearly specifies that how member URIs with a link relation of
> "edit"
> > should be used.
>
> How is `<link rel="edit" ...` in an Atom document different than a
> property `http://example.com/vocab/modify-by-putting-here` that points
> to the "member" resource in RDF?

The difference is that the media type specifies the semantics. Whereas in
RDF the user specifies the semantics. You won't find them in the media type
specification of RDF/XML, Turtle, etc. The subject of this thread is
"formats with native hypermedia support going beyond GET".


> > Would you say the same is true for form@method="get" and
> form@method="post"?
> > I don't think any client out there will issue a GET when a POST is
> defined
> > or the other way round.. The same applies for a a@rel="edit" link in
> an Atom
> > document.
>
> I don't think (m)any clients would try to get the resource from a POST
> form.  However, they are welcome to if they want. That is part of the
> uniform interface. Every resource responses to every method.

True, but it gives the server a way to show the client how to navigate
through his resource space. Sure, that's also possible with RDF and the like
but the semantics are shifted from the media type to the ontology.



--
Markus Lanthaler
@markuslanthaler

On Wed, Jan 18, 2012 at 7:51 PM, Markus Lanthaler
<markus.lanthaler@...> wrote:
> The difference is that the media type specifies the semantics. Whereas in
> RDF the user specifies the semantics. You won't find them in the media type
> specification of RDF/XML, Turtle, etc. The subject of this thread is
> "formats with native hypermedia support going beyond GET".

Ah, i see your point now. So a media type that was defined as "data
encoded in the foo vocabulary and serialized as json-ld" could,
depending on the properties defined in the vocabulary, pass muster on
this front?

Why aren't all RDF properties (whose values are a resource) equivalent
to `<a>` tags but where the media type is saying that any method is
ok?

Peter
barelyenough.org

On Friday, January 20, 2012 3:57 AM, Peter Williams wrote:
> Ah, i see your point now. So a media type that was defined as "data
> encoded in the foo vocabulary and serialized as json-ld" could,
> depending on the properties defined in the vocabulary, pass muster on
> this front?
>
> Why aren't all RDF properties (whose values are a resource) equivalent
> to `<a>` tags but where the media type is saying that any method is
> ok?

Even <a> tags in HTML don't disallow other methods than GET. The point is
that there's no way to define, e.g., the query parameters or the expected
body of a POST/PUT whereas HTML natively supports to describe such aspects
with forms. In RDF, that knowledge, again, has to be documented somewhere
out of band - possibly in an ontology.

So, coming back to my original question, does anyone knows other media types
which natively support hypermedia that goes beyond a simple GET?

The current list is:
- HTML (GET/POST/PUT)
- Atom+AtomPub (GET/POST/PUT/DELETE)
- WSDL (GET/POST/PUT/DELETE)
- WADL (GET/POST/PUT/HEAD/DELETE)
- Collection+JSON (GET/POST/PUT/DELETE)
- CCXML (GET/POST) - thanks to Erlend
- Shoji (GET/POST/PUT/DELETE) - thanks to Robert


I have another list of media types with built-in support for a "semantic"
annotation of links (which can be used to support other methods by
describing the details out-of-band):
- HTML
- Atom+AtomPub
- HAL
- RDF/XML, Turtle, N3, JSON-LD, ...
- WADL/WSDL??



--
Markus Lanthaler
@markuslanthaler

"Markus Lanthaler" wrote:
>
> Even <a> tags in HTML don't disallow other methods than GET.
>

Don't forget that method in hypertext, is also a function of URI.  I
wish this list was easier to search, I know I re-wrote the HTML 4.01
text concerning form methods and posted it here as an example, once.
Instead of HTTP methods, HTML should use tokens descriptive of sender
intent.  Because if the URI is mailto: the method won't be POST, will
it?  Even though that's what it says in the markup?

I'd rather see protocol-agnostic markup rather than bindings to specific
protocols, regardless of media type...

-Eric

Mike Kelly wrote:
>
> Eric J. Bowman wrote:
>
> > **
> >
> >
> > "Markus Lanthaler" wrote:
> > >
> > > Even <a> tags in HTML don't disallow other methods than GET.
> > >
> >
> > Don't forget that method in hypertext, is also a function of URI. I
> > wish this list was easier to search, I know I re-wrote the HTML 4.01
> > text concerning form methods and posted it here as an example, once.
> > Instead of HTTP methods, HTML should use tokens descriptive of
> > sender intent. Because if the URI is mailto: the method won't be
> > POST, will it? Even though that's what it says in the markup?
> >
> > I'd rather see protocol-agnostic markup rather than bindings to
> > specific protocols, regardless of media type...
> >
> >
> I think that's interesting.. but I'm not clear where and how you
> would map these protocol-agnostic control elements to the various
> protocols/URI schemes, if you don't do it in the media type.
>

Where does any such mapping exist for links in HTML?

http://www.w3.org/TR/html4/struct/links.html

Clearly, the semantics are retrieval, it's up to the client developer
what protocols to support over time, and map to the appropriate method
in the intermediary or user-agent code which implements the media type.
Browsers still understand the ftp: scheme, but dropped gopher: in 2010.

This change in scheme support affects all supported media types.  It is
orthogonal to media type, so don't protocol-bind your media types.  HTML
has seen protocols come and go, and will continue to be served over
HTTP 2.0 with yet another port # and URI scheme and perhaps different
method names -- this has always made its HTTP form bindings look rather
quaint, IOW method='get' should be operation='retrieve' with no more
discussion of protocol than for <a> and <link/>, as in none whatsoever.

-Eric

> > I think that's interesting.. but I'm not clear where and how you
> > would map these protocol-agnostic control elements to the various
> > protocols/URI schemes, if you don't do it in the media type.
> >
>
> Where does any such mapping exist for links in HTML?
>
> http://www.w3.org/TR/html4/struct/links.html
>
> Clearly, the semantics are retrieval

Is that really that clear? It is just the default behavior of browsers and
thus, by far, the most common one (at least for HTTP, what about mailto,
e.g.?). The semantics depend, on the rel and rev attributes according to
that document.


> This change in scheme support affects all supported media types.  It is
> orthogonal to media type, so don't protocol-bind your media types.
> HTML has seen protocols come and go, and will continue to be served over
> HTTP 2.0 with yet another port # and URI scheme and perhaps different
> method names

That's true.. but I don't know how feasible that really is. HTML sits on top
of an application level protocol (HTML or something else) which has its own
semantics that might not always match 1:1 to HTML semantics.. Again, think
of a mailto-link. How should a client retrieve such a "web resource"? It's
simple not possible, and yet mailto-links and even forms work.


> this has always made its HTTP form bindings look rather
> quaint, IOW method='get' should be operation='retrieve' with no more
> discussion of protocol than for <a> and <link/>, as in none whatsoever.

But it wasn't specified that way. It was clearly bound to the HTTP methods..
Nevertheless browsers are able map these HTTP semantics to other schemes -
is that really any different? There's still time to change that for HTML5 if
you think that it would be important to change this:

http://dev.w3.org/html5/spec/Overview.html#attr-fs-method



--
Markus Lanthaler
@markuslanthaler