Hi Richard, Thanks for your comments and some clarifications.
On Mon, Jul 8, 2019 at 12:10 PM Y. Richard Yang <[email protected]> wrote: > Some quick additional comments. Please see inline. > > On Fri, Jul 5, 2019 at 6:02 PM Jensen Zhang <[email protected]> > wrote: > >> Hi ALTOers, >> >> After some internal discussions, we are happy to update to WG that we are >> finalizing the unified properties draft. And below are some key design >> points: >> >> --- >> >> 1. Consider UP (Unified Property Map) service as a unified ATLO >> information resources query mechanism >> >> ALTO defines different types of information resources, which have >> different representation formats. But every information resource can map >> some kinds of entities to some kinds of properties. e.g., a network map can >> map ipv4 to pid. >> > > Slight clarification. So far it is not every type of information resource. > For example, cost may cannot yet, unless we introduce flow/connection, but > we may say some for now. > > Agree. We will clarify it is extensible. The future document can define new mappings for existing ALTO information resources. > > >> UP provides a query mechanism to allow clients to get different ALTO >> information resources in the unified representation format. >> >> > We should clarify that UP provides 3 functions, as we did in the quad > chart: export, extend, and define. The preceding may give others an > impression that it limits us to only the first. > > It will be clarified in the document. > 2. Each UP resource declares a set of (resource_i, DT) -> { (resource_ok, >> Pk) } mappings >> >> > Can we use r_i, d_i -> r_o, p_o? > > >> Here, resource_ok MUST be either resource_i or this (the current UP >> resource itself). >> >> - When resource_ok == resource_i, the mapping means the client can query >> the property mapping DT -> Pk defined by resource_i. e.g., "ipv4" -> "pid" >> defined by "networkmap-1". >> - When resource_ok == this, the mapping means the client can query >> entities in the entity domain resource_i.DT, and UP will return the >> property P defined in its own backend database. >> >> The semantics of entity domain resource_i.DT MUST be defined in the IANA >> registry of resource type of resource_i >> The semantics of mapping DT -> Pk MUST be defined in the IANA registry of >> resource type of resource_ok. >> >> 2.1. Use DT -> { (resource_ok, Pk) } as a shortcut of the aggregation >> >> A UP resource can declare "ipv4" -> { ("net1", "pid"), ("net2", "pid") }. >> It is equivalent to the outer join of ("net1", "ipv4") -> ("net1", "pid") >> and ("net2", "ipv4") -> ("net2", "pid"). In this UP, "ipv4" indicates the >> union of entity domain "net1.ipv4" and "net2.ipv4". >> >> > I do not know what the outer join is. A simple rule is a kind of > *inheritance* rule: > > d_i -> (ro1, po1), (ro2, po2), ..., > > <=> > > (ro1, d_i) -> (ro1, po1); > (ro2, d_i) -> (ro2, po2), > ... > > In words, the result is to use the output resource. > > Thanks for your clarification. *inheritance* may be a better clarification. the (ro1, po1) of d_i:e_i (an entity in d_i) inherits (ro1, po1) of ro1.d_i:e_i (the entity in (ro1, d_i) with the same id). > > >> 3. The client sends the UP query based on the declaration >> >> > It helps that we make clear the declare-use consistent design. Hence the > final format of capability may be: > > // design 1 > query-capability: a list of mapping > mapping: domain -> properties > > properties: a list of properties > property: resource-prop | this-prop > resource-prop: r_o.p_o // (r_o, p_o) > this-prop: .p_o // (this, p_o) > > domain: resource-domain | generic-domain > resource-domain: r_i.d_i > generic-domain: d_i > > Semantics: > - resource-domain (r_i, d_i) -> properties > is equivalent to (r_i, d_i) -> each property in properties > > - generic-domain -> properties > use the inheritance rule above > > Consistency requirements: > Export consistency, which applies to > an individual-mapping (r_i, d_i) -> (r_o, p_o), where r_i == r_o != > this > 1.1 Capability announcement consistency: > d_i -> p_o must be supported by resource r_i > 1.2. Content consistency > (r_i, d_i) -> (r_o, p_o) lookup result is the same as one uses > r_i itself. > Extend consistency, which applies to > an individual-mapping (r_i, d_i) -> (r_o, p_o), where r_o == this > The domain (r_i, d_i) must be supported by r_i > > Thanks for your clarification again. I agree with the requirements above. The document will include them. Jensen > Make sense? > > Richard > > >> The client queries a list of entities in resource_i.DT or DT, and a >> subset of properties { (resource_ok, Pk) }. >> >> --- >> >> We will finish the document revision in the next two days. In the >> meantime, your comments and feedback are highly welcomed. >> >> Thanks, >> Jensen >> > > > -- > -- > ===================================== > | Y. Richard Yang <[email protected]> | > | Professor of Computer Science | > | http://www.cs.yale.edu/~yry/ | > ===================================== >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
