Enrico, On May 8, 2013 4:17 AM, "Enrico Marocco" <[email protected]> wrote: > > Hi Richard, > > since the new version has been submitted, the actual section with the > example you mention is 8.5.3 > (http://tools.ietf.org/html/draft-ietf-alto-protocol-15#section-8.5.3).
Yes. > On the substance of the question, I believe it's essential to have the > syntax flexible enough to reflect proper semantics. However -- forgive > the JavaScript speak -- with the current specification the distinction > between "leaf" and "container" would basically require a check on > (media-types.length == 1), while with the proposed change it would turn > out to (typeof media-types == "string"), correct? It can be more complex. For example, the just submitted version allows IRD to announce multipe cost types of an unfiltered cost map with a single media type. Hence we have a case that media-types has a length of 1 but we do not have a leaf node. As another example. Consider a possible future extension, where we may consider allowing two media types for one IR: for example, both the current cost map format or a new matrix format. Hence, IRD could announce two media types for it, and ALTO Clients can indicate one using http Accept in request. Hence, we have a case of media-types with length > 1, but we have a leaf. Regardless indicating leaf vs non-leaf explicitly, I do not foresee encountering non-encodable problems with the current spec. There can be some difference in ease of implementation. My personal preference is explicit leaf nodes and hence no need for a Client to request an IR but get an IRD back. But the current spec works and can be more compact for IRD representation. Thanks! Richard > > If that's the case, honestly I don't see a big gain in doing it. But I'm > not an implementor nor have a strong preference, so I'll let others > express more articulated opinions. Either way works for me. > > Enrico > > On 5/7/13 10:18 PM, Y. Richard Yang wrote: > > Dear all, > > > > As we work to finalize a newer version to get feedback, here is a quick > > question that we need feedback/comments to have a quick closure. The > > issue can be discussed using the current posted version > > ( http://datatracker.ietf.org/doc/draft-ietf-alto-protocol/?include_text=1), > > although we will post a newer version soon. > > > > Specifically, consider the first IRD example in Sec. 7.6.3. One can > > identify that among the six entries, 5 are base or "leaf" entries, which > > represent specific Information Resources, and one is a "container" entry: > > > > { > > "uri" : "http://custom.alto.example.com/maps";, > > "media-types" : [ > > "application/alto-networkmap+json", > > "application/alto-costmap+json" > > ], > > "accepts" : [ > > "application/alto-networkmapfilter+json", > > "application/alto-costmapfilter+json" > > ] > > }, > > > > In other words, one can envision that IRD can be a hierarchy for > > flexibility and delegation. > > > > A question is whether we explicitly distinguish such two types of > > entries in syntax -- they are different in semantics already. > > > > Note that distinguishing the two types by simply checking the number of > > entries in media-types or accepts will be less robust. > > > > One possibility is the following. A "leaf" IRD entry has the format: > > "uri": "" > > > > "media-type": "" > > "accept": "" > > "capabilities" : {} > > > > A "container" IRD has the format: > > "uri" : > > "media-types" : [] > > "accepts" : [] > > // no capabilities > > > > Any thought? > > > > Richard > > > > > > > > > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
