multiple properties with WF

[Melvin Carvalho]

I've only just noticed that properties and links a different in that properties is an object and links are an array, meaning that, a link can have many values, but a property only one.

For example looking at:

[[

       {
           "http://example.com/ns/role/" : "employee"
       }

]]

So what if Bob is BOTH an employee, and a CEO?

In the links array I could simply add another element, but with properties, it would overwrite what was there.

So does this mean webfinger keys are limited to those properties that can take at most one value, or do we have another way round this, like comma separating?

One thing I come across commonly is a nick, e.g. on IRC, forums etc. people sometimes have more than one

[Paul E. Jones]

Melvin,

 

The subject-level properties are limited to one property of any given type.  In this example (which is just an example, so don’t read too much into this), a possible way to represent that Bob is the CEO might be to have a different property to indicate his title (e.g., “http://example.com/ns/title”).

 

At present, there are no formally-defined properties.  As those are defined, one must carefully select property identifiers such that there is no need to have more than one.

 

In any case, property identifiers can be any URI, so it’s certainly possible to be very granular in defining properties.  So, I think we should be able to find a way to avoid a need for an array.  In the case of IRC nicknames, if one wanted to define those as properties for some reason, one might define them like this:

 

"http://example.com/irc-nick#<network>" : "bob"

 

Here, the URI fragment “<network>” might be “efnet” or “dalnet” or other network name.  Alternatively, one might prefer a single property like this:

 

"http://example.com/irc-nick" : "efnet:bob,dalnet:pumpkin"

 

The value is a string and, if necessary, could be defined as a comma-separated set of values.  However, I would not recommend that, since it introduces special parsing considerations on a type basis.  That said, others might see it differently and prefer this over using URI fragments.  It’s really up to the users of WebFinger to define how this will work.

 

Paul

 

--
 
---
You received this message because you are subscribed to the Google Groups "WebFinger" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webfinger+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Melvin Carvalho]

On 20 August 2013 04:20, Paul E. Jones <pau...@packetizer.com> wrote:

Melvin,

 

The subject-level properties are limited to one property of any given type.  In this example (which is just an example, so don’t read too much into this), a possible way to represent that Bob is the CEO might be to have a different property to indicate his title (e.g., “http://example.com/ns/title”).

 

At present, there are no formally-defined properties.  As those are defined, one must carefully select property identifiers such that there is no need to have more than one.

 

In any case, property identifiers can be any URI, so it’s certainly possible to be very granular in defining properties.  So, I think we should be able to find a way to avoid a need for an array.  In the case of IRC nicknames, if one wanted to define those as properties for some reason, one might define them like this:

 

"http://example.com/irc-nick#<network>" : "bob"

 

Here, the URI fragment “<network>” might be “efnet” or “dalnet” or other network name.  Alternatively, one might prefer a single property like this:

 

"http://example.com/irc-nick" : "efnet:bob,dalnet:pumpkin"

 

The value is a string and, if necessary, could be defined as a comma-separated set of values.  However, I would not recommend that, since it introduces special parsing considerations on a type basis.  That said, others might see it differently and prefer this over using URI fragments.  It’s really up to the users of WebFinger to define how this will work.

I actually went through my network and this doesnt happen too often from what I saw.

There was two nicks for : timbl , TimBL 

And 4 for nick: "silverbucket", "slvrbckt", "hurphendale", "nkj"

I noticed one person had two phone numbers which were 'literals'

I suspect adding comma separated variables could be a tricky way to go in this respect, im curious as to why properties and links are treated differently, or is it something inherited from XRD?

[Paul E. Jones]

Melvin,

 

The JRD format was first defined in RFC 6415.  The current WebFinger spec uses the same syntax.  In RFC 6415, the properties relating to the subject were defined as an object.  The XRD format actually allowed for multiple elements of the same type, but RFC 6415 did not allow that representation in the JRD.  It says explicitly that ‘if more than one "Property" element is present with the same "type" attribute, only the last instance is included.’  Further, RFC 6415 defined “properties” as an object, not array.

 

I’m not sure why that decision was made in RFC 6415.  I can only assume that the intent was that properties should be type/value pairs where there is a single property of a given type.

[Melvin Carvalho]

On 20 August 2013 20:19, Paul E. Jones <pau...@packetizer.com> wrote:

Melvin,

 

The JRD format was first defined in RFC 6415.  The current WebFinger spec uses the same syntax.  In RFC 6415, the properties relating to the subject were defined as an object.  The XRD format actually allowed for multiple elements of the same type, but RFC 6415 did not allow that representation in the JRD.  It says explicitly that ‘if more than one "Property" element is present with the same "type" attribute, only the last instance is included.’  Further, RFC 6415 defined “properties” as an object, not array.

 

I’m not sure why that decision was made in RFC 6415.  I can only assume that the intent was that properties should be type/value pairs where there is a single property of a given type.

Thanks so much, very interesting!