Loading ...
Sorry, an error occurred while loading the content.

19478Re: [rest-discuss] Re: [apps-discuss] New Version Notification for draft-nottingham-link-hint-00.txt

Expand Messages
  • Erik Wilde
    Jun 24 9:49 PM
    • 0 Attachment
      hello mark.

      On 2013-06-24 21:17 , Mark Nottingham wrote:
      >> but i have one question about the general registry model: the current draft says that hints MUST have a name (very reasonable, of course), but also that hints MUST have their data model being defined in JSON.
      >> http://tools.ietf.org/html/draft-nottingham-link-hint-00#section-5.1
      >> living in a world where we have JSON services, XML services, and RDF services, it seems that hard-coding a specific language data model into such a spec (without constraining it in any way) will limit the utility of such a registry.
      > It needs *a* data model.

      yes, that's definitely true. i think what i'm trying to figure out a
      first is whether there is any precedence of a registry requiring a JSON
      data model, or any other specific language for that matter, for a
      structured values. it seems it's mostly specific micro-syntaxes (if any
      structure beyond identifiers is required), but i am really wondering
      about what people have usually done in similar situations.

      >> for example, in the Home Document draft, which is the original source of the link hint idea, the hints were hard-coded with very constrained data models. this made it relatively easy to expose them in a different syntax (in the XML Home Document draft):
      >> http://tools.ietf.org/html/draft-wilde-home-xml-01#page-4
      >> without getting too much into the details of this specific registry: what are the best practices about allowing/controlling language dependencies in registries?
      > Whoa, hold on - who said anything about a language? This is just the underlying data model; you can express it in a document however makes sense.

      that's kind of true, but not really. since the draft allows *any* kind
      of JSON, if i had a non-JSON document format (let's say XML ;-) that
      wanted to be able to represent registry values in general, it needs to
      define a generic mapping from *any* kind of JSON to XML. that's
      technically possible, but not really what works well for any non-JSON
      document model.

      i think this is my main argument: if you have a micro-syntax for the
      registry, you can map that much easier to something that maps reasonably
      well into a variety of document models. if you require JSON, and allow
      arbitrary JSON, the JSON bias translates into rather inconvenient models
      for any non-JSON language.

      >> personally, i would feel more comfortable with having a registry that is of equal value to people regardless of their implementation language
      > You're using "language" quite loosely here.

      maybe. and like i said above, apart from having implementation concerns
      about non-JSON formats, i am also really interested to learn about prior
      art: how was this problem approached/solved in other situations like this?

      >> , but then again that means that the registry itself must define a "mini-language" of its own.
      > -1. Defining Yet Another Data Model as a political solution to avoid picking an existing one is sub-optimal at best.

      not sure. if JSON is #1 on the requirement list, then maybe define a
      well-defined subset of JSON, so that mappings into other languages don't
      need to be able to handle *any* JSON?

      more specifically, what do the current hints actually need? it seems
      that the set of possibilities is actually rather small. for example,
      http://tools.ietf.org/html/draft-nottingham-link-hint-00#section-3.2
      says "Content MUST be an object, whose keys are media types, and values
      are objects", but what are the objects containing? maybe a simple array
      of media type strings would suffice? and then, if we can boil down the
      needs to "hints are strings or arrays of strings", then we can create
      good mappings for a variety of document models, and not just for JSON.

      cheers,

      dret.

      --
      erik wilde | mailto:dret@... - tel:+1-510-2061079 |
      | UC Berkeley - School of Information (ISchool) |
      | http://dret.net/netdret http://twitter.com/dret |
    • Show all 12 messages in this topic