Re: [apps-discuss] WebFinger payload as array or object

[James M Snell <[e-mail]>]

Better approach where order doesn't matter...

    { ...
        "links": [
            {"rel": "icon", "href": "/tiny.png"},
            {"rel": "icon", "href": "/big-n-shiny.png", "media": "only
screen and (min-device-pixel-ratio : 2)"}
        ]
    }


On Thu, Nov 29, 2012 at 1:55 PM, Joseph Holsten <[e-mail]>wrote:

> "I want a pretty icon to represent this account," says the web app. "I
> know, I'll see what their webfinger says!"
>
>     { ...
>         "links": [
>             {"rel": "apple-touch-icon-precomposed", "href":
> "/big-n-shiny.png"},
>             {"rel": "icon", "href": "/tiny.png"}
>         ]
>     }
>
>
> --
> http://josephholsten.com
>
> On Nov 29, 2012, at 13:22, Mike Kelly <[e-mail]> wrote:
>
> > That makes sense, I was wondering what kind of application behaviour
> > would need a way to indicate preference between links of different
> > rel? I can't envisage that use-case.
> >
> > On Thu, Nov 29, 2012 at 7:43 PM, Paul E. Jones <[e-mail]>
> wrote:
> >> Several times, people have asked "how do I know which of n things is the
> >> most preferred".  Ordering is a good way to indicate preference.
> >>
> >> Paul
> >>
> >>> -----Original Message-----
> >>> From: [e-mail] [mailto:apps-discuss-
> >>> [e-mail]] On Behalf Of Mike Kelly
> >>> Sent: Thursday, November 29, 2012 11:56 AM
> >>> To: mike amundsen
> >>> Cc: Joe Gregorio; IETF Apps Discuss; [e-mail]
> >>> Subject: Re: [apps-discuss] WebFinger payload as array or object
> >>>
> >>> Hey Mike,
> >>>
> >>> I'm not sure I understand the use-case for selecting a link on the
> basis
> >>> of the order in which it appears in the representation.. not over and
> >>> above selecting by rel anyway. I think it might help me to see an
> >>> example where a client would need to select a link this way.
> >>>
> >>> Are you bringing this up as a small point of difference or a
> fundamental
> >>> advantage?
> >>>
> >>> Cheers,
> >>> M
> >>>
> >>> On Thu, Nov 29, 2012 at 4:41 PM, mike amundsen <[e-mail]>
> wrote:
> >>>> jumping in here...
> >>>>
> >>>> keep in mind that JSON/Javascript does not retain ordering for hash
> >>>> dictionaries, but *does* retain ordering for arrays.
> >>>>
> >>>> for this reason, i have adopted a style similar to your "Plan A" when
> >>>> sending link collections in the JSON format; esp. when that collection
> >>>> might vary over time (or via context details of the request).
> >>>>
> >>>> Cheers.
> >>>>
> >>>> mamund
> >>>> +1.859.757.1449
> >>>> skype: mca.amundsen
> >>>> http://amundsen.com/blog/
> >>>> http://twitter.com/mamund
> >>>> https://github.com/mamund
> >>>> http://www.linkedin.com/in/mikeamundsen
> >>>>
> >>>>
> >>>>
> >>>> On Thu, Nov 29, 2012 at 11:37 AM, Melvin Carvalho
> >>>> <[e-mail]>
> >>>> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 29 November 2012 17:29, James M Snell <[e-mail]> wrote:
> >>>>>>
> >>>>>>
> >>>>>> On Thu, Nov 29, 2012 at 8:19 AM, Tim Bray <[e-mail]>
> >>> wrote:
> >>>>>>>
> >>>>>>> This thread has bifurcated, so I'm going to formalize that with a
> >>>>>>> subject change.
> >>>>>>>
> >>>>>>> On this thread, please argue about turning the WebFinger payload
> >>>>>>> inside
> >>>>>>> out:
> >>>>>>>
> >>>>>>> Plan A:
> >>>>>>>
> >>>>>>> "links" : [
> >>>>>>> { "rel":  "rel1", "href" : "http://example/1", "type" :
> >>>>>>> "text/plain" },  { "rel":  "rel2", "href" : "http://example/2"
> >>> "type" :
> >>>>>>> "application/json" }
> >>>>>>> ]
> >>>>>>>
> >>>>>>> Plan B:
> >>>>>>>
> >>>>>>> "links" : {
> >>>>>>> "rel1" : { "href" : "http://example/1", "type" : "text/plain" },
> >>>>>>> "rel2" : { "href" : "http://example/2"  "type" :
> "application/json"
> >>>>>>> }  }
> >>>>>>
> >>>>>> Plan C:
> >>>>>>
> >>>>>> "links" : {
> >>>>>> "rel1" : [{ "href" : "http://example/1", "type" : "text/plain" },
> >>>>>>             { "href" : "http://example/2", "type" : "text/plain"
> >>>>>> }],  "rel2" : [{ "href" : "http://example/3"  "type" :
> >>>>>> "application/json" }]  }
> >>>>>>
> >>>>>> For me, the options are Plan A or Plan C, as those are the only ones
> >>>>>> that allow multiple instances of a single link relation. Plan A
> >>>>>> requires you to process through the whole set of links to find all
> >>>>>> instances of a single link relation. Plan C allows you to select
> >>>>>> individual link relations and then process that specific array of
> >>> links.
> >>>>>
> >>>>>
> >>>>> Like Plan C also ... seems very similar (perhaps isomorphic?) to plan
> >>>>> A with a slightly neater syntax.
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> My take: It doesn't matter very much.  Plan A feels a little
> >>>>>>> cleaner to me, but it's not worth the time/energy to argue over.
> >>>>>>> -T
> >>>>>>
> >>>>>> Agreed. Again, this mainly just comes down to painting the barn
> >>> really.
> >>>>>>
> >>>>>> - James
> >>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Thu, Nov 29, 2012 at 8:02 AM, Melvin Carvalho
> >>>>>>> <[e-mail]> wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 29 November 2012 16:50, James M Snell <[e-mail]>
> >>> wrote:
> >>>>>>>>>
> >>>>>>>>> +1 to everything Tim and Joe have said. Simpler is better.
> >>>>>>>>>
> >>>>>>>>> Fwiw, the approach I took with JSON activity streams [1] was to
> >>>>>>>>> use rel values as member names to make client code more
> >>>>>>>>> efficient, and have the values be arrays of link objects to
> >>>>>>>>> allow multiple links...
> >>>>>>>>>
> >>>>>>>>> E.g....
> >>>>>>>>>
> >>>>>>>>> {
> >>>>>>>>>  "blog": [
> >>>>>>>>>    {"href": "http://...", ...},
> >>>>>>>>>    {"href": "http://...", ...}
> >>>>>>>>>  ]
> >>>>>>>>> }
> >>>>>>>>>
> >>>>>>>>> I know this part mostly comes down to a style choice, but this
> >>>>>>>>> structure ends up being very efficient when it comes to picking
> >>>>>>>>> out just the link relations you want while ignoring everything
> >>>>>>>>> else.
> >>>>>>>>
> >>>>>>>> You may find this reference page valuable
> >>>>>>>>
> >>>>>>>> http://www.w3.org/2011/rdf-wg/wiki/JSON-Serialization-Examples
> >>>>>>>>
> >>>>>>>> It contains various json serialization standards
> >>>>>>>>
> >>>>>>>> 1.2.1 Shared Example for Serialization Lineup (Turtle)
> >>>>>>>> 1.2.2 Linked Data API
> >>>>>>>> 1.2.3 JRON
> >>>>>>>> 1.2.4 JSN3
> >>>>>>>> 1.2.5 JSON-LD (CURIEs)
> >>>>>>>> 1.2.6 JSON-LD (terms)
> >>>>>>>> 1.2.7 JTriples
> >>>>>>>> 1.2.8 RDF/JSON
> >>>>>>>> 1.2.9 RDFj
> >>>>>>>> 1.2.10 SPARQL Query Results in JSON
> >>>>>>>> 1.2.11 Flat triples approach to RDF graphs in JSON
> >>>>>>>>
> >>>>>>>> Essentially the common parts are part of the Entity Attribute
> >>>>>>>> Value model (aka subject predicate object)
> >>>>>>>>
> >>>>>>>> Activity streams is also a neat serialization with its own
> >>>>>>>> content type.
> >>>>>>>>
> >>>>>>>> Personally I think JRD is one of the weaker serializations out
> >>> there.
> >>>>>>>> Though it seems incredibly tightly coupled to webfinger, for
> >>>>>>>> historical, and perhaps some social, reasons.  I've yet to hear
> >>>>>>>> the full rationale for this, articulated.
> >>>>>>>>>
> >>>>>>>>> - james
> >>>>>>>>>
> >>>>>>>>> On Nov 29, 2012 6:11 AM, "Joe Gregorio" <[e-mail]>
> >>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> On Thu, Nov 29, 2012 at 12:36 AM, Paul E. Jones
> >>>>>>>>>> <[e-mail]>
> >>>>>>>>>> wrote:
> >>>>>>>>>>> Joe,
> >>>>>>>>>>>
> >>>>>>>>>>> But, the JRD syntax is already defined.  Just pretend XRD
> >>>>>>>>>>> never existed.
> >>>>>>>>>>> Look at JRD on its own.  It's simple.  Why go make a bunch of
> >>>>>>>>>>> changes to it now?
> >>>>>>>>>>
> >>>>>>>>>> I don't think Tim's proposal is a large number of changes, his
> >>>>>>>>>> proposal drops expires which doesn't belong in the file, and it
> >>>>>>>>>> drops properties.
> >>>>>>>>>>
> >>>>>>>>>> I don't think properties, at the links level, are a good thing
> >>>>>>>>>> and the sample from the spec for configuring a printer is a
> >>>>>>>>>> perfect example:
> >>>>>>>>>>
> >>>>>>>>>>    {
> >>>>>>>>>>      "rel" : "http://example.net/rel/smtp-server",
> >>>>>>>>>>      "properties" :
> >>>>>>>>>>      {
> >>>>>>>>>>        "host" : "smtp.example.com",
> >>>>>>>>>>        "port" : "587",
> >>>>>>>>>>        "login-required" : "yes",
> >>>>>>>>>>        "transport" : "starttls"
> >>>>>>>>>>      }
> >>>>>>>>>>    },
> >>>>>>>>>>
> >>>>>>>>>> That really should be:
> >>>>>>>>>>
> >>>>>>>>>>    {
> >>>>>>>>>>      "rel" : "http://example.net/rel/smtp-server",
> >>>>>>>>>>      "href": "https://smtp.packetizer.com/config.dat"
> >>>>>>>>>>    },
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Where https://smtp.packetizer.com/config.dat is a file format
> >>>>>>>>>> that contains the information in the properties, such as host,
> >>>>>>>>>> port, transport, etc.
> >>>>>>>>>>
> >>>>>>>>>> I think that keeps the WebFinger story simple, the file format
> >>>>>>>>>> is basic information about the entity you queried about
> >>>>>>>>>> (subject, alias, properties), and then links related to that
> >>>>>>>>>> entity.
> >>>>>>>>>>
> >>>>>>>>>> I don't believe WebFinger won't get wide adoption if you can't
> >>>>>>>>>> put SMTP configuration info directly into the WF response.
> >>>>>>>>>>
> >>>>>>>>>> I don't believe WebFinger won't get wide adoption if you have
> >>>>>>>>>> to do two requests to find that SMTP configuration info.
> >>>>>>>>>>
> >>>>>>>>>> I do believe WebFinger will get wide adoption if the format is
> >>>>>>>>>> as simple as possible.
> >>>>>>>>>>
> >>>>>>>>>> I would be fine with keeping the top level properties object.
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> I can appreciate documenting all of JRD fully in the spec.
> >>>>>>>>>>> Who wants to do that?  I don't want to write that.  Was Tim
> >>>>>>>>>>> volunteering?
> >>>>>>>>>>
> >>>>>>>>>> Yes, I believe Tim was volunteering to do that, but he can
> >>>>>>>>>> answer for himself.
> >>>>>>>>>>
> >>>>>>>>>>  -joe
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Paul
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Joe Gregorio        http://bitworking.org
> >>>>>>>>>> _______________________________________________
> >>>>>>>>>> apps-discuss mailing list
> >>>>>>>>>> [e-mail]
> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/apps-discuss
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> _______________________________________________
> >>>>>>>>> apps-discuss mailing list
> >>>>>>>>> [e-mail]
> >>>>>>>>> https://www.ietf.org/mailman/listinfo/apps-discuss
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> apps-discuss mailing list
> >>>>>>>> [e-mail]
> >>>>>>>> https://www.ietf.org/mailman/listinfo/apps-discuss
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> apps-discuss mailing list
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/apps-discuss
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> apps-discuss mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/apps-discuss
> >>>
> >>>
> >>>
> >>> --
> >>> Mike
> >>>
> >>> http://twitter.com/mikekelly85
> >>> http://github.com/mikekelly
> >>> http://linkedin.com/in/mikekelly123
> >>> _______________________________________________
> >>> apps-discuss mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/apps-discuss
> >
> >
> >
> > --
> > Mike
> >
> > http://twitter.com/mikekelly85
> > http://github.com/mikekelly
> > http://linkedin.com/in/mikekelly123
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>