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 protected]> wrote:
> 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:
>
>> It appears that we have a consensus on this. Hence, we will update.
>>
>> Richard
>>
>>
>> On Fri, Jul 19, 2013 at 3:37 AM, Richard Alimi <[email protected]>wrote:
>>
>>> Works for me.
>>>
>>>
>>> On Wed, Jul 17, 2013 at 12:37 PM, Y. Richard Yang <[email protected]>wrote:
>>>
>>>> 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 protected]> wrote:
>>>>
>>>>> I like it. Ben
>>>>>
>>>>> On 17 Jul 2013, at 19:27, Wendy Roome wrote:
>>>>>
>>>>> > 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
>>>>> >
>>>>> >
>>>>> > _______________________________________________
>>>>> > alto mailing list
>>>>> > [email protected]
>>>>> > https://www.ietf.org/mailman/listinfo/alto
>>>>>
>>>>> _______________________________________________
>>>>> alto mailing list
>>>>> [email protected]
>>>>> https://www.ietf.org/mailman/listinfo/alto
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> alto mailing list
>>>> [email protected]
>>>> https://www.ietf.org/mailman/listinfo/alto
>>>>
>>>>
>>>
>>
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
