Fwd: WebFinger payload as array or object

FYI:

Tim Bray (creator of XML) is talking about a JSON serialization effort at
the IETF for webfinger, that may get deployed by google, microsoft and
others.

There seems to be some overlap with JSON LD, feel free to add thoughts to
the ietf mailing list if some of these issues have already been fielded.

---------- Forwarded message ----------
From: Tim Bray <tbray@textuality.com>
Date: 29 November 2012 17:19
Subject: WebFinger payload as array or object
To: Melvin Carvalho <melvincarvalho@gmail.com>
Cc: James M Snell <jasnell@gmail.com>, IETF Apps Discuss <
apps-discuss@ietf.org>, webfinger@googlegroups.com, Joe Gregorio <
joe@bitworking.org>


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" }
 }

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


On Thu, Nov 29, 2012 at 8:02 AM, Melvin Carvalho
<melvincarvalho@gmail.com> wrote:
>
>
> On 29 November 2012 16:50, James M Snell <jasnell@gmail.com> 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" <joe@bitworking.org> wrote:
>>>
>>> On Thu, Nov 29, 2012 at 12:36 AM, Paul E. Jones <paulej@packetizer.com>
>>> 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
>>> apps-discuss@ietf.org
>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>
>>
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>