On Wed, Jul 24, 2013 at 2:24 PM, Y. Richard Yang <[email protected]> wrote:
> 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" > > Sorry, a typo: resources[x].media-type == "application/alto-networkmap+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
