Subject: [alto] What about making service IDs JSON keys?

From: Wendy Roome <[email-masked]>
Date: Wed, 17 Jul 2013 14:27:32 -0400

Folks,

Since each IRD resource must have a unique ID, why not structure the
"resources" field of an IRD as a JSON dictionary, with the ID names as
keys?  Eg,

"resources" : {
   "default-network-map": {
       "uri" : "http://alto.example.com/networkmap",
       "media-type" : "application/alto-networkmap+json"
   },
   "numerical-routing-cost-map": {
       "uri" : "http://alto.example.com/costmap/num/routingcost",
       "media-type" : "application/alto-costmap+json",
       "capabilities" : {
           "cost-type-names" : [ "num-routing" ]
       },
       "uses": [ "default-network-map" ]
   },
   ......

Yes, that's a change. But that also forces the server to provide unique
ids. If not, you get a JSON parse error.

That also makes it clear that a server's set of IRDs collectively define a
map from ids to resource descriptors. I suspect that when given an IRD,
most clients will build an in-memory map with he ids as keys, and will
follow any IRD links until they've added every resource to that table.

	- Wendy Roome

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 17 Jul 2013 19:43:40 +0100

I like it. Ben

On 17 Jul 2013, at 19:27, Wendy Roome wrote:

> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto

---

From: "Y. Richard Yang" <[email-masked]>
Date: Wed, 17 Jul 2013 15:37:04 -0400

It is very clean indeed. I do not see any problem for now, but will think
about it over night.

Richard

---

From: Richard Alimi <[email-masked]>
Date: Fri, 19 Jul 2013 00:37:57 -0700

Works for me.

On Wed, Jul 17, 2013 at 12:37 PM, Y. Richard Yang <[email-masked]> wrote:

> On Wed, Jul 17, 2013 at 2:43 PM, Ben Niven-Jenkins <
> [email-masked]> wrote:
>
>> I like it. Ben
>>

---

From: "Y. Richard Yang" <[email-masked]>
Date: Fri, 19 Jul 2013 17:45:26 -0400

It appears that we have a consensus on this. Hence, we will update.

Richard

---

From: "Y. Richard Yang" <[email-masked]>
Date: Wed, 24 Jul 2013 10:20:55 -0400

Hi all,

My apologies to reopen this thread.

One "concern" of making the IRD data structure a resource ID -> resource
object hash map is whether we can still leverage YANG to express "must"
constraints easily, should we eventually use YANG as a more formal grammar.
My understanding is that YANG uses XPATH for expression of predicates. Any
comment from YANG experts on the mailing list?

Thanks!

Richard

On Friday, July 19, 2013, Y. Richard Yang wrote:

> On Fri, Jul 19, 2013 at 3:37 AM, Richard Alimi <[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>
> > wrote:
>
>> Works for me.
>>
>>
>> On Wed, Jul 17, 2013 at 12:37 PM, Y. Richard Yang <[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>
>> > wrote:
>>
>>> It is very clean indeed. I do not see any problem for now, but will
>>> think about it over night.
>>>
>>> Richard
>>>
>>>
>>> [email-masked] <javascript:_e({}, 'cvml',
>>> [email-masked]');>> wrote:
>>>
>>>> I like it. Ben
>>>>
>>>> > [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>
>>>> [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>
>>> [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>

---

From: "Y. Richard Yang" <[email-masked]>
Date: Wed, 24 Jul 2013 14:24:09 -0400

I was asked on some specific examples of predicates to express constraints
and consistency checks. Here are a few examples. I will use p => q as a
boolean operator, and if you do not like it, you can rewrite it as (!p or
q):

1. any entry used in a cost-type-names entry of a capabilities must be
defined:

  assume x is an entry in a cost-type-names: ird.meta.cost-types[x] is not
empty, where we use [x] for associate array index

2. any resource id used in "uses" is defined

 assume x is a resource id used in a uses field: x in resources.keys, if we
define resources as a hash map from resource id to entries

3. the resource id in the "uses" field of a cost map is a network map

 assume x is a resource id used in the uses field: resources[x].media-type
== "application/alto-costmap+json"

4. if a cost map is unfiltered, it should have only one entry in its
cost-type-names

resources[x].media-type == "application/alto-costmap+json"
&& resources[x].accepts == ""
           => resources[x].capabilities.cost-type-names.length == 1

It looks that we do not encounter problems in expressing some major boolean
predicates that we want to express. We will discuss the issue at the IETF
meeting and make a final decision there. Any offline comments before the
meeting will be appreciated!

Thanks!

Richard

On Wed, Jul 24, 2013 at 10:20 AM, Y. Richard Yang <[email-masked]> wrote:

>> On Fri, Jul 19, 2013 at 3:37 AM, Richard Alimi <[email-masked]>wrote:
>>
>>> Works for me.
>>>
>>>
>>> On Wed, Jul 17, 2013 at 12:37 PM, Y. Richard Yang <[email-masked]>wrote:
>>>

---

From: "Y. Richard Yang" <[email-masked]>
Date: Wed, 24 Jul 2013 14:26:24 -0400

On Wed, Jul 24, 2013 at 2:24 PM, Y. Richard Yang <[email-masked]> wrote:

>  assume x is a resource id used in a uses field: x in resources.keys, if
> we define resources as a hash map from resource id to entries
>
Sorry, a typo: resources[x].media-type == "application/alto-networkmap+json"

> It looks that we do not encounter problems in expressing some major
> boolean predicates that we want to express. We will discuss the issue at
> the IETF meeting and make a final decision there. Any offline comments
> before the meeting will be appreciated!
>
> Thanks!
>
> Richard
>
>
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 26 Jul 2013 08:55:55 +0100

Richard,

On 24 Jul 2013, at 15:20, Y. Richard Yang wrote:

> One "concern" of making the IRD data structure a resource ID -> resource object hash map is whether we can still leverage YANG to express "must" constraints easily, should we eventually use YANG as a more formal grammar. 

To be blunt, I don't see any value in worrying about whether using the id as the dictionary key might break something that we might end up doing eventually.

Using the id as the key is elegant & it suits our needs today so I say let's just roll with it.

Ben

> My understanding is that YANG uses XPATH for expression of predicates. Any comment from YANG experts on the mailing list?
> 
> Thanks!
> 
> Richard
> 
> It is very clean indeed. I do not see any problem for now, but will think about it over night.
> 
> Richard
> 
> 
> On Wed, Jul 17, 2013 at 2:43 PM, Ben Niven-Jenkins <[email-masked]> wrote:
> I like it. Ben
>

---

From: "Y. Richard Yang" <[email-masked]>
Date: Fri, 26 Jul 2013 16:40:17 -0400

Hi Ben,

Thanks for sharing the opinion. I checked a few predicates and do not see
major problems using xpath syntax. We will proceed with the change of using
resource ids as keys in the next version.

Thanks!

Richard
On Jul 26, 2013 3:56 AM, "Ben Niven-Jenkins" <[email-masked]>
wrote:

> To be blunt, I don't see any value in worrying about whether using the id
> as the dictionary key might break something that we might end up doing
> eventually.
>
> > My understanding is that YANG uses XPATH for expression of predicates.
> Any comment from YANG experts on the mailing list?
> >
> > Thanks!
> >
> > Richard
> >