3 ms·

It would be useful because it would provide a standard way of expressing a hyperlink. URLs are a standard way of expressing the location of a resource, HTTP is

It would be useful because it would provide a standard way of expressing a hyperlink. URLs are a standard way of expressing the location of a resource, HTTP is a standard mechanism for interacting with resources, but there are no widely-used standards for expressing "here's a URL". XLink and RDF tried to become standards for that, but they haven't caught on. The text/html content type (and its close relatives) are widely understood and include a couple of syntaxes for different types of links, and that's why I like xhtml as my API content type. If JSON had a standard widely understood syntax for links I'd happily switch over since JSON is certainly more popular as a RESTful API content type. Imagine where we would be if every website expressed links using a different syntax, and browsers had to be explicitly programmed to understand a given website's syntax in order to use its links. The web couldn't exist that way.

icebraining 15y ago
XHTML is great for web pages, but it's a poor format if you want to transmit very structured data. There's no way in X(HTML) to say "this is a user", "this is user X's name", "this is user X's email address", etc. Frankly, if I GET an URL from your API describing a certain user's profile, and I get a blob of unstructured text, I won't use your service for long. XHTML + RDFa is a different case, but that's hardly well understood, especially the specific ontologies. It's really no better ATM than using a custom JSON based format.
- DougWebb 15y ago
  <div data-role="user"> <span data-role="name">...</span> <span data-role="email">...</span> </div> In general, I agree with you that XHTML isn't a great format for structured data. One advantage that XML has over JSON is the ability to attach attributes to data elements. I find that useful, and much easier to use than JSON's best alternative which is to turn a simple data element into a dictionary object. { key: "value" } { key: { attr1: "attr1val", attr2: "attr2val", value: "value" } } <div>value</div> <div attr1="attr1val" attr2="attr2val">value</div> In the XML markup, you can retrieve the value the same way in both cases. With the JSON markup you have to use different syntax to retrieve the value depending upon whether or not there are attributes, which means you'll wind up always using nested objects if the attributes are optional, just to have consistent syntax. What's odd about this is that in Javascript, attributes (aka Properties) can be attached to anything. You want your string variable to have some properties? No problem. You want some of those properties to be functions? Go for it. You want your function to have methods? Enjoy. I'm surprised that JSON didn't include this capability, since it exists in Javascript and is also a big distinguishing factor between JSON and XML. Getting back to hyperlinks as a datatype, JSON uses "" for strings, [] for lists, {} for dictionaries/objects, and key: value for key/value pairs. Why not add <...> for hyperlinks as a special kind of string? The ... could just be a url, or it could be a url followed by a comma-separated list of standard attributes like rel="..." and label="...". It's a small addition, but I think if it was right there in the markup syntax it would become widely used, and software which parses and works with JSON could depend upon it being there and build higher-level functionality on top of it.
  - icebraining 15y ago
    <div data-role="user"> <span data-role="name">...</span> <span data-role="email">...</span> </div> Those attributes aren't defined in the XHTML spec. You've essentially created a new (custom) format on top of XHTML. It's no better than any of the custom formats based on JSON. What's odd about this is that in Javascript, attributes (aka Properties) can be attached to anything. You want your string variable to have some properties? No problem. You want some of those properties to be functions? Go for it. You want your function to have methods? Enjoy. I'm surprised that JSON didn't include this capability, since it exists in Javascript and is also a big distinguishing factor between JSON and XML Now every JSON parser would have to embed a Javascript interpreter to be complete. That would make it completely impossible to implement in a huge number of cases, not to mention the headaches with security (the halting problem, for example) and performance.
    - DougWebb 15y ago
      data-* is an HTML5 attribute: http://dev.w3.org/html5/spec/Overview.html#embedding-custom-non-visible-data-with-the-data-attributes http://dev.w3.org/html5/spec/Overview.html#embedding-custom-... The standard says that specific data-* attributes are only intended to be used by the site that generates the markup, but I think it's fair to say that an API using them can give semantic meaning to them for the use by any code using the API, without violating the standard.
      - icebraining 15y ago
        Sure, and the same can be done in JSON.

icebraining 15y ago

XHTML is great for web pages, but it's a poor format if you want to transmit very structured data. There's no way in X(HTML) to say "this is a user", "this is user X's name", "this is user X's email address", etc. Frankly, if I GET an URL from your API describing a certain user's profile, and I get a blob of unstructured text, I won't use your service for long. XHTML + RDFa is a different case, but that's hardly well understood, especially the specific ontologies. It's really no better ATM than using a custom JSON based format.

DougWebb 15y ago
<div data-role="user"> <span data-role="name">...</span> <span data-role="email">...</span> </div> In general, I agree with you that XHTML isn't a great format for structured data. One advantage that XML has over JSON is the ability to attach attributes to data elements. I find that useful, and much easier to use than JSON's best alternative which is to turn a simple data element into a dictionary object. { key: "value" } { key: { attr1: "attr1val", attr2: "attr2val", value: "value" } } <div>value</div> <div attr1="attr1val" attr2="attr2val">value</div> In the XML markup, you can retrieve the value the same way in both cases. With the JSON markup you have to use different syntax to retrieve the value depending upon whether or not there are attributes, which means you'll wind up always using nested objects if the attributes are optional, just to have consistent syntax. What's odd about this is that in Javascript, attributes (aka Properties) can be attached to anything. You want your string variable to have some properties? No problem. You want some of those properties to be functions? Go for it. You want your function to have methods? Enjoy. I'm surprised that JSON didn't include this capability, since it exists in Javascript and is also a big distinguishing factor between JSON and XML. Getting back to hyperlinks as a datatype, JSON uses "" for strings, [] for lists, {} for dictionaries/objects, and key: value for key/value pairs. Why not add <...> for hyperlinks as a special kind of string? The ... could just be a url, or it could be a url followed by a comma-separated list of standard attributes like rel="..." and label="...". It's a small addition, but I think if it was right there in the markup syntax it would become widely used, and software which parses and works with JSON could depend upon it being there and build higher-level functionality on top of it.
- icebraining 15y ago
  <div data-role="user"> <span data-role="name">...</span> <span data-role="email">...</span> </div> Those attributes aren't defined in the XHTML spec. You've essentially created a new (custom) format on top of XHTML. It's no better than any of the custom formats based on JSON. What's odd about this is that in Javascript, attributes (aka Properties) can be attached to anything. You want your string variable to have some properties? No problem. You want some of those properties to be functions? Go for it. You want your function to have methods? Enjoy. I'm surprised that JSON didn't include this capability, since it exists in Javascript and is also a big distinguishing factor between JSON and XML Now every JSON parser would have to embed a Javascript interpreter to be complete. That would make it completely impossible to implement in a huge number of cases, not to mention the headaches with security (the halting problem, for example) and performance.
  - DougWebb 15y ago
    data-* is an HTML5 attribute: http://dev.w3.org/html5/spec/Overview.html#embedding-custom-non-visible-data-with-the-data-attributes http://dev.w3.org/html5/spec/Overview.html#embedding-custom-... The standard says that specific data-* attributes are only intended to be used by the site that generates the markup, but I think it's fair to say that an API using them can give semantic meaning to them for the use by any code using the API, without violating the standard.
    - icebraining 15y ago
      Sure, and the same can be done in JSON.