Comments on: Unobtrusive link info http://barelyenough.org/blog/2010/01/unobtrusive-link-info/ … and there is much to be learned Sun, 06 May 2012 15:09:26 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: Peter Williams http://barelyenough.org/blog/2010/01/unobtrusive-link-info/comment-page-1/#comment-83921 Peter Williams Tue, 08 Jun 2010 16:43:26 +0000 http://barelyenough.org/?p=416#comment-83921 <p>Reda B.,</p> <p>There are advantages of using a standard link mechanism, such as a atom:link element or a xlink attribute. Using standardized linking structures allow clients that do not understand the semantics of your doctype to extract some link related information. Such standardization should allow libraries to be built that are less media type specific, and therefore more reusable.</p> <p>That being said i think that the <code>Link</code> header field is a better way to deal with the sorts of links that benefit from standardization.</p> Reda B.,

There are advantages of using a standard link mechanism, such as a atom:link element or a xlink attribute. Using standardized linking structures allow clients that do not understand the semantics of your doctype to extract some link related information. Such standardization should allow libraries to be built that are less media type specific, and therefore more reusable.

That being said i think that the Link header field is a better way to deal with the sorts of links that benefit from standardization.

]]> By: Reda B. http://barelyenough.org/blog/2010/01/unobtrusive-link-info/comment-page-1/#comment-83783 Reda B. Wed, 02 Jun 2010 18:06:10 +0000 http://barelyenough.org/?p=416#comment-83783 <p>Sorry i had some problems with formatting</p> Sorry i had some problems with formatting

]]> By: Reda B. http://barelyenough.org/blog/2010/01/unobtrusive-link-info/comment-page-1/#comment-83782 Reda B. Wed, 02 Jun 2010 18:05:43 +0000 http://barelyenough.org/?p=416#comment-83782 <p>Like integer or plain string, i think link should be treated as a data type. Link as an element is just too vague. Of course with the "rel" attribte it is self describing, but just take a look at Peter's example of a self describing document. I looks more like a xsd than a xml ! May be the use of Link element is encouraged since it is thought to be a fundamental peace of data in the web and should be easily recognizable, hence an element named Link. But what is a link worth if you don't know where it takes you, the semantic ? May be there might be use cases for parsing links without caring (or caring less) about the linked resource, well, for that, it is not really hard for a parser to know if an element value is a link or not.</p> <p>Peter, may be i'm wrong but isn't less cumbersome <code> </code> Than <code> mailto:pezra@barelyenough.org personal </code></p> <p>Aren't you keeping some "meta-meta data" in the document ? shouldn't the consumer just know that email tag ? or is the purpose to maintain the generic aspect of the link ?</p> Like integer or plain string, i think link should be treated as a data type. Link as an element is just too vague. Of course with the “rel” attribte it is self describing, but just take a look at Peter’s example of a self describing document. I looks more like a xsd than a xml !
May be the use of Link element is encouraged since it is thought to be a fundamental peace of data in the web and should be easily recognizable, hence an element named Link. But what is a link worth if you don’t know where it takes you, the semantic ?
May be there might be use cases for parsing links without caring (or caring less) about the linked resource, well, for that, it is not really hard for a parser to know if an element value is a link or not.

Peter, may be i’m wrong but isn’t less cumbersome


Than

mailto:pezra@barelyenough.org
personal

Aren’t you keeping some “meta-meta data” in the document ? shouldn’t the consumer just know that email tag ? or is the purpose to maintain the generic aspect of the link ?

]]> By: Reda B. http://barelyenough.org/blog/2010/01/unobtrusive-link-info/comment-page-1/#comment-83781 Reda B. Wed, 02 Jun 2010 18:05:11 +0000 http://barelyenough.org/?p=416#comment-83781 <p>Like integer or plain string, i think link should be treated as a data type. Link as an element is just too vague. Of course with the "rel" attribte it is self describing, but just take a look at Peter's example of a self describing document. I looks more like a xsd than a xml ! May be the use of Link element is encouraged since it is thought to be a fundamental peace of data in the web and should be easily recognizable, hence an element named Link. But what is a link worth if you don't know where it takes you, the semantic ? May be there might be use cases for parsing links without caring (or caring less) about the linked resource, well, for that, it is not really hard for a parser to know if an element value is a link or not.</p> <p>Peter, may be i'm wrong but isn't less cumbersome <code> </code><code> Than </code><code> mailto:pezra@barelyenough.org personal </code></p> <p>Aren't you keeping some "meta-meta data" in the document ? shouldn't the consumer just know that email tag ? or is the purpose to maintain the generic aspect of the link ?</p> Like integer or plain string, i think link should be treated as a data type. Link as an element is just too vague. Of course with the “rel” attribte it is self describing, but just take a look at Peter’s example of a self describing document. I looks more like a xsd than a xml !
May be the use of Link element is encouraged since it is thought to be a fundamental peace of data in the web and should be easily recognizable, hence an element named Link. But what is a link worth if you don’t know where it takes you, the semantic ?
May be there might be use cases for parsing links without caring (or caring less) about the linked resource, well, for that, it is not really hard for a parser to know if an element value is a link or not.

Peter, may be i’m wrong but isn’t less cumbersome


Than

mailto:pezra@barelyenough.org
personal

Aren’t you keeping some “meta-meta data” in the document ? shouldn’t the consumer just know that email tag ? or is the purpose to maintain the generic aspect of the link ?

]]> By: Peter Williams - What are links http://barelyenough.org/blog/2010/01/unobtrusive-link-info/comment-page-1/#comment-79707 Peter Williams - What are links Thu, 07 Jan 2010 05:56:37 +0000 http://barelyenough.org/?p=416#comment-79707 <p>[...] am still not a fan of the link element. This example is a good one in every other regard. [...]</p> [...] am still not a fan of the link element. This example is a good one in every other regard. [...]

]]> By: Peter Williams http://barelyenough.org/blog/2010/01/unobtrusive-link-info/comment-page-1/#comment-79697 Peter Williams Wed, 06 Jan 2010 15:41:17 +0000 http://barelyenough.org/?p=416#comment-79697 <p>As a user of the data the linkyness of a property is far less important than the semantics of the property. The fact that i have a persons primary email address is important. Having a link w/o knowing what it means is of no value.</p> <p>I don't love the idea of a link attribute but it does provide a useful benefit. Given the IANA link relation registry, if a standard way of tagging arbitrary XML nodes at containing URIs of a particular relation it would allow clients to extract some value even from formats that they do not completely understand. I see it as a more practical way to get the perceived benefits of the <code>link</code> element.</p> <p>The <code>link</code> element trades clarity of encoding and simplicity in native client for visibility of links to generic link rel clients. I just don't think we have to give up all the clarity and simplicity to gain that visibility.</p> As a user of the data the linkyness of a property is far less important than the semantics of the property. The fact that i have a persons primary email address is important. Having a link w/o knowing what it means is of no value.

I don’t love the idea of a link attribute but it does provide a useful benefit. Given the IANA link relation registry, if a standard way of tagging arbitrary XML nodes at containing URIs of a particular relation it would allow clients to extract some value even from formats that they do not completely understand. I see it as a more practical way to get the perceived benefits of the link element.

The link element trades clarity of encoding and simplicity in native client for visibility of links to generic link rel clients. I just don’t think we have to give up all the clarity and simplicity to gain that visibility.

]]> By: Mike Amundsen http://barelyenough.org/blog/2010/01/unobtrusive-link-info/comment-page-1/#comment-79688 Mike Amundsen Wed, 06 Jan 2010 05:41:06 +0000 http://barelyenough.org/?p=416#comment-79688 <p>I think elements named LINK are "first order" members of the type. I think elements named "Email" w/ an attribute named "link" are less direct expressions of links.</p> <p>What am I missing?</p> <p>BTW - I was actually re-reading the XLink spec this past weekend!</p> I think elements named LINK are “first order” members of the type. I think elements named “Email” w/ an attribute named “link” are less direct expressions of links.

What am I missing?

BTW – I was actually re-reading the XLink spec this past weekend!

]]> By: Peter Williams http://barelyenough.org/blog/2010/01/unobtrusive-link-info/comment-page-1/#comment-79677 Peter Williams Tue, 05 Jan 2010 17:59:13 +0000 http://barelyenough.org/?p=416#comment-79677 <p>My point was that the <code>link</code> element is not even used uniformly in Atom. Many of the links defined by Atom are implemented with constructs other than the <code>link</code> element. I don't think this is bad. It is just an indication that the <code>link</code> element construct is quite awkward in many situations.</p> <p>I think we improve the situation by creating a less awkward approach to self describing links.</p> My point was that the link element is not even used uniformly in Atom. Many of the links defined by Atom are implemented with constructs other than the link element. I don’t think this is bad. It is just an indication that the link element construct is quite awkward in many situations.

I think we improve the situation by creating a less awkward approach to self describing links.

]]> By: Subbu Allamaraju http://barelyenough.org/blog/2010/01/unobtrusive-link-info/comment-page-1/#comment-79674 Subbu Allamaraju Tue, 05 Jan 2010 14:11:30 +0000 http://barelyenough.org/?p=416#comment-79674 <p>I'm surprised at your comment on Atom's use of links. Atom and AtomPub use links for hypertext. Extensibilty is inherent in hypertext.</p> I’m surprised at your comment on Atom’s use of links. Atom and AtomPub use links for hypertext. Extensibilty is inherent in hypertext.

]]> By: uberVU - social comments http://barelyenough.org/blog/2010/01/unobtrusive-link-info/comment-page-1/#comment-79664 uberVU - social comments Tue, 05 Jan 2010 07:24:30 +0000 http://barelyenough.org/?p=416#comment-79664 <p><strong>Social comments and analytics for this post...</strong></p> <p>This post was mentioned on Twitter by mamund: Peter Williams - Unobtrusive link info http://ff.im/-dO8Pd...</p> Social comments and analytics for this post…

This post was mentioned on Twitter by mamund: Peter Williams – Unobtrusive link info http://ff.im/-dO8Pd…

]]>