5 ms·

> No, there's no need for it, you can just define it in your own media type I don't want to define my own media type, because if I define my own media type onl

> No, there's no need for it, you can just define it in your own media type I don't want to define my own media type, because if I define my own media type only clients that are designed to understand my media type can use my API. I want to use a media type that clients can already interact with in standard ways. I want my clients to be able to do something like this: var url = hyperlink(resourceData, linkRel).href; That way they need to know the value of linkRel they're interested in (semantic knowledge of my API) but nothing about the structure of my resourceData object. When I use xhtml, this works (with jQuery): var url = $(resourceData).find("a[rel=" + linkRel + "]").attr("href");

icebraining 15y ago
The point is that just as XHTML is a format built over XML, there can be (and are) standard formats built over JSON. You don't need URL support in JSON, just like you don't have it in XML and yet you can still identify links in a format based on it. For example, the JSON Activity Streams[1] is a standard format, supported by plenty of 'big names' (Google, Opera, Gowalla, etc), which defines a schema under which certain keys ("url") are to be considered URLs/links. [1]: http://activitystrea.ms/ http://activitystrea.ms/
- DougWebb 15y ago
  Thanks for the link, but you're proving my point: if I'm building an application that consumes Activity Stream resources, and also other kinds of resources, I have to have a different interpreter to understand and follow links in these different resource types. I don't have to do that for strings, numbers, lists, or dictionaries because those are standard datatypes in JSON. I think we're at a point now where hyperlinks should be a standard datatype too. A second-best alternative would be a standard way to express hyperlinks in JSON using the existing datatypes. I don't think a key:value pair with a key named 'url' is sufficient though; hyperlinks need metainfo so you can differentiate them from each other and give them semantic meaning, like the 'rel' attribute does in xhtml. I think labels are important too, though they're not always needed. The problem with this approach is that it's reinventing RDF and XLink in JSON, and RDF and XLink have already failed to be broadly adopted. I think part of the problem with them is the need for an add-on interpreter in addition to the syntax interpreter. If RDF or XLink interpreters were baked-into HTML and XML parsers so that the linking info they provide were as much a part of the syntax as elements, attributes, and strings, they might have become widely used.
  - deleted 15y ago
    [deleted]
  - icebraining 15y ago
    > if I'm building an application that consumes Activity Stream resources, and also other kinds of resources, I have to have a different interpreter to understand and follow links in these different resource types. I don't have to do that for strings, numbers, lists, or dictionaries because those are standard datatypes in JSON. I think we're at a point now where hyperlinks should be a standard datatype too. But you still need to know what that number, list or dictionary means. By itself, what does [3, 5, 6, 2] mean? Nothing. Likewise, you'll know that string X is a link because you know the format. And the exact problem exists with XLink. Let's say I'm parsing a user profile and there's an XLink there. To where does that link point to? The user's personal website? To his mother's profile? To a song he likes? XLink is only useful if you don't care and are just displaying it to the user. Most of these APIs are supposed to be consumed by machines, hence they need to have more structured formats. Having that, XLink is irrelevant. > hyperlinks need metainfo so you can differentiate them from each other and give them semantic meaning, like the 'rel' attribute does in xhtml. As I said previously, that's provided by the format, which the client needs to understand anyway. I know an 'url' inside an 'Image' object represents the URI I can access the Image data from. I know an 'url' inside a 'Friend' object represents that person's profile page, etc. > The problem with this approach is that it's reinventing RDF and XLink in JSON, and RDF and XLink have already failed to be broadly adopted. I think part of the problem with them is the need for an add-on interpreter in addition to the syntax interpreter. If RDF or XLink interpreters were baked-into HTML and XML parsers so that the linking info they provide were as much a part of the syntax as elements, attributes, and strings, they might have become widely used. RDF is another example of a format that's useless by itself. Sure, you know that X is an URL, but an URL of what? The client needs to understand the domain ontology. Knowing that, it's obvious what is and isn't an URL.
    - DougWebb 15y ago
      [3, 5, 6, 2] is a list; I have standard tools for iteration over the list and for getting the length of the list. These allow the creation of other tools that build upon the basic tools: filtering, transformation, reduction, unions, differences, etc. I have this rich toolset for working with lists because lists are a standard datatype; if the syntax for expressing a list were different for every list I wanted to work with, none of these tools could exist. The 'meaning' of the list, within the context of a specific API, is of course specific to that API. That's the semantic meaning I've been mentioning. My ideal is where you only need to document the semantic meaning, and not the syntax that is used to represent that meaning. The syntax should be standardized.

icebraining 15y ago

The point is that just as XHTML is a format built over XML, there can be (and are) standard formats built over JSON. You don't need URL support in JSON, just like you don't have it in XML and yet you can still identify links in a format based on it. For example, the JSON Activity Streams[1] is a standard format, supported by plenty of 'big names' (Google, Opera, Gowalla, etc), which defines a schema under which certain keys ("url") are to be considered URLs/links. [1]: http://activitystrea.ms/ http://activitystrea.ms/

DougWebb 15y ago
Thanks for the link, but you're proving my point: if I'm building an application that consumes Activity Stream resources, and also other kinds of resources, I have to have a different interpreter to understand and follow links in these different resource types. I don't have to do that for strings, numbers, lists, or dictionaries because those are standard datatypes in JSON. I think we're at a point now where hyperlinks should be a standard datatype too. A second-best alternative would be a standard way to express hyperlinks in JSON using the existing datatypes. I don't think a key:value pair with a key named 'url' is sufficient though; hyperlinks need metainfo so you can differentiate them from each other and give them semantic meaning, like the 'rel' attribute does in xhtml. I think labels are important too, though they're not always needed. The problem with this approach is that it's reinventing RDF and XLink in JSON, and RDF and XLink have already failed to be broadly adopted. I think part of the problem with them is the need for an add-on interpreter in addition to the syntax interpreter. If RDF or XLink interpreters were baked-into HTML and XML parsers so that the linking info they provide were as much a part of the syntax as elements, attributes, and strings, they might have become widely used.
- deleted 15y ago
  [deleted]
- icebraining 15y ago
  > if I'm building an application that consumes Activity Stream resources, and also other kinds of resources, I have to have a different interpreter to understand and follow links in these different resource types. I don't have to do that for strings, numbers, lists, or dictionaries because those are standard datatypes in JSON. I think we're at a point now where hyperlinks should be a standard datatype too. But you still need to know what that number, list or dictionary means. By itself, what does [3, 5, 6, 2] mean? Nothing. Likewise, you'll know that string X is a link because you know the format. And the exact problem exists with XLink. Let's say I'm parsing a user profile and there's an XLink there. To where does that link point to? The user's personal website? To his mother's profile? To a song he likes? XLink is only useful if you don't care and are just displaying it to the user. Most of these APIs are supposed to be consumed by machines, hence they need to have more structured formats. Having that, XLink is irrelevant. > hyperlinks need metainfo so you can differentiate them from each other and give them semantic meaning, like the 'rel' attribute does in xhtml. As I said previously, that's provided by the format, which the client needs to understand anyway. I know an 'url' inside an 'Image' object represents the URI I can access the Image data from. I know an 'url' inside a 'Friend' object represents that person's profile page, etc. > The problem with this approach is that it's reinventing RDF and XLink in JSON, and RDF and XLink have already failed to be broadly adopted. I think part of the problem with them is the need for an add-on interpreter in addition to the syntax interpreter. If RDF or XLink interpreters were baked-into HTML and XML parsers so that the linking info they provide were as much a part of the syntax as elements, attributes, and strings, they might have become widely used. RDF is another example of a format that's useless by itself. Sure, you know that X is an URL, but an URL of what? The client needs to understand the domain ontology. Knowing that, it's obvious what is and isn't an URL.
  - DougWebb 15y ago
    [3, 5, 6, 2] is a list; I have standard tools for iteration over the list and for getting the length of the list. These allow the creation of other tools that build upon the basic tools: filtering, transformation, reduction, unions, differences, etc. I have this rich toolset for working with lists because lists are a standard datatype; if the syntax for expressing a list were different for every list I wanted to work with, none of these tools could exist. The 'meaning' of the list, within the context of a specific API, is of course specific to that API. That's the semantic meaning I've been mentioning. My ideal is where you only need to document the semantic meaning, and not the syntax that is used to represent that meaning. The syntax should be standardized.