Hi Wendy, Good discussions. Here is some background on my thinking: a frame that I liked a lot of modern programming language design is type theory, which tries to enforce correctness (or more realistically, prevent bugs), through syntax.
Now, let's consider the issue of providing full NMs. Here is some reasoning: - An ALTO service can have multiple NMs that it does not provide to a specific client, due to access control. This is legitimate. Hence, the issue is not that an ALTO service must provide every NM as a resource. - Hence, the issue is an ALTO Service provides a resource of a filtered NM without specifying the base full NM. This syntax problem reveals some semantics issues. First, underlying, there can be two cases: - the filtered NM is based on a full NM which is specified in an announced resource, - the filtered NM is based on a full NM which is not specified in an announced resource. >From the IRD, the client cannot distinguish between the two cases (we require that there is always a default full NM). Second, the map vtag in the response to a query through a filtered NM should indicate the base full NM. Consider two filtered NM entries (say due to load balancing) based on the same full NM. If the map vtag is the resource name of the filtering resource name, this is not ideal, because vtag should name the data, not the program accessing the data. By adding the "uses" to indicate the resource name of a full NM in a filtered NM, we solve the two issues. Note that these two issues are different from the issue of if ALTO should provide a full NM uri if it provides a filtering uri. There are alternatives to using "uses" to solve the issues. One example is to introduce an NM name attribute. This alternative reveals that the current design couples name and locator. In other words, what is the meaning of a resource name? Does an filtered NM need a name? The bugs you pointed out below are interesting. We will specify in the revision the conditions for the "uses" to indicate the correct type. Thanks! Richard On Tuesday, August 13, 2013, Wendy Roome wrote: > I don't think that's enough; I think it's much better to explicitly say > that a server MUST provide a full NM resource for each NM. > > If we just say that a filtered NM must have a "uses" attribute, then a > server might define a filtered NM that uses a nonexistent resource ID. The > associated cost maps would use that nonexistent resource as well. Yes, most > people will assume that the dependent resource must exist -- but I don't > think the protocol actually requires that. > > BTW, a sleazy implementor might even declare the filtered NM as "using" > itself. > > In any case, we should say that a filtered NM MUST have a "uses" clause > for a *full* NM. Otherwise a filtered NM is not very useful -- it would be > in limbo, and a client could not connect it with any cost maps. > > Also, we should say that cost maps must "use" a full network map resource, > not a filtered one. > > > - Wendy > > From: "Y. Richard Yang" <[email protected] <javascript:_e({}, 'cvml', > '[email protected]');>> > Date: Sun, August 11, 2013 13:24 > To: Wendy Roome <[email protected] <javascript:_e({}, 'cvml', > '[email protected]');>> > Cc: IETF ALTO <[email protected] <javascript:_e({}, 'cvml', '[email protected]');> > > > Subject: Re: [alto] required resources > > On Aug 9, 2013 11:16 AM, "Wendy Roome" > <[email protected]<javascript:_e({}, 'cvml', > '[email protected]');>> > wrote: > > > > I have a few questions about required resources that need to be > clarified, > > especially in the case of multiple network maps. > > > > > > 1. {10.1.1} says that a server MUST provide at least one full Network Map > > resource. If a server has multiple network maps, it can satisfy that > > requirement by providing a full NM resource for one map -- and it doesn't > > have to be the default map -- and filtered network map resources for the > > others. > > > > I'm not a big fan of requirements, but I do think a network map isn't > very > > useful unless the server is willing to give the full map. So I suggest > > changing {10.1.1} to say, "An ALTO Server MUST provide a Network Map > > resource for each Network Map." > > In -17, there is no "uses" for a filtered network map. Hence, one may not > know from which base NM a filtered NM is derived. So with your proposal, if > we require that each filtered NM MUST have a "uses" to declare the base NM, > the problem is solved. Do I understand it correct? >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
