On Wed, Jul 17, 2013 at 9:13 AM, Wendy Roome <[email protected]>wrote:
> A few comments on the new id and uses fields in the IRD:
>
> * In the last part of {8.5.2}, shouldn't there be an entry describing the
> "id" field?
>
>
Yes - that is missing. We will add it. Thanks for pointing it out.
> * In the "custom" IRD in {8.5.4}, I assume the "filtered-network-map"
> service returns a subset of the full map returned by
> "default-network-map". So shouldn't that entry say that it uses
> "default-network-map"?
>
>
Yes - I think it should. We'll fix that and ensure the document says that
this should be done for filtered network maps.
>
> * {8.5.2} says "uses" is an array. That's general, obviously, but can
> anyone give an example of why "uses" would have more than one entry? For
> that matter, when would "uses" ever refer to anything other than a full
> network map service?
>
Example: filtered cost map uses the full cost map and the full network map.
(We'll also fix the text in the document to state this explicitly.)
>
> (At first I thought we'd need multiple entries to indicate that the client
> could get the map from a full or filtered map service. But I think it's
> much cleaner to say that the filtered network map service depends on the
> full service.)
>
Agreed.
>
>
> * The "custom" IRD in {8.5.4} depends on the "example" IRD in {8.5.3}, but
> doesn't link to it. So by itself, the "custom" IRD is useless; the client
> must also know about the "example" IRD.
>
> Does that bother anyone?
>
> That means that discovery should only return "parent" IRDs, like
> "example", not "child" IRDs like "custom."
>
Correct. There was a response by Ben about this in another thread, and I
agree with the assessment there that its up to the client to have visited
the relevant pages. In other words, I personally agree its not worth
guarding against clients who are "eager" and forget where they came from.
>
>
> * When IRDs link to other IRDs, do we require that the links form a
> non-looping rooted tree? If so, fine; a client can easily start at the
> root and walk the tree. But if links can loop, then the client has to
> determine whether it's visited an IRD before. Unfortunately the client
> cannot simply compare the URIs, because URI's aren't canonical. In
> particular, redirection could mean that the client's idea of the root
> IRD's URI might not be identical to what the ALTO server provider idea of
> the root IRD's URI.
>
> So the client needs some other mechanism to determine if it's visited an
> IRD before. I suppose it could use the set of resource IDs as a key, but
> that's a hassle. I think the easiest solution is to require that each IRD
> in the set have a unique "id". Eg, add an IRD "id" field at the top level,
> along with "meta" and "resources".
>
ALTO Clients need to handle circular redirects from HTTP anyways, and this
is a very similar problem. If a client wants to do something more
intelligent than just a hard cap on the number of redirects, then one
possibility would be to come up with a fingerprint for an IRD which is a
function of the resource IDs that the IRD describes.
Rich
> - 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
