| RE: [higgins-dev] Constraining a Digital Subject's attributes |
|
Why do we need the notion of "compound" attributes to be part of the model? If an attribute's value is allowed to be any type, then the consumer would discover an attribute's type (I believe this is done using the attribute's identifier).
Building the notion of compound attributes into the model gives the capability brought up in this thread (the parts of the attribute are named, and given the required interfaces could potentially be read with a path-like identifier). But again, any attribute value is free do define ways of doing that anyway.
Jim >>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> 5/24/06 3:09 PM >>> Hmm... have you thought at all yet about how to express the set of attributes in this "hint" _expression_? Since the attributes can be compound (complex gaggles of objects), there would need to be a way to refer to not just "leaf" attributes on a DigitalSubject but also to "branches" of attributes. You could think of this hint as the description of a subset of the schema of the Context. Jim wrote: > > When getting a DigitalSubject from a Context, I think the caller needs a > way to (optionally) constrain the attributes/relationships held on the > DigitalSubject. Maybe "constrain" gives the wrong impression. The caller > needs to be able to provide a list of attributes it intends to consume. > > Given that some context providers will use network protocols to > gather/produce DigitalSubjects within a context, and given that the > amount/size of all possible attributes on a DigitalSubject may be very > large, the possibility of causing undue performance problems exists > unless there is the ability of the caller to specify a list of > attributes/relationships to be associated with a DigitalSubject being > interrogated. > > Here's an example: > > A context provider uses LDAP as its store. A caller asks for a > DigitalSubject by name. The underlying context provider performs the > LDAP search operation to locate and read the named object, and return a > DigitalSubject using the information returned. > > Now, the provider didn't know which attributes would ultimately be > read, so it either: a) read all attributes from the LDAP server, or b) > read none, or c) read a few configured ones. > > In terms of avoiding further network traffic, the best bet is (a). But > in this case, the provider may have performed a very expensive operation > as LDAP objects may be populated with large numbers of attributes of > large size. OTOH, (b) may, and (c) will result in the provider sending > further protocol requests to gather attributes as they are being read > from the DigitalSubject. > > Does anyone see problems in adding a mechanism to instruct the context > provider which attributes will be read? > > Jim > > _______________________________________________ > higgins-dev mailing list > higgins-dev@xxxxxxxxxxx > https://dev.eclipse.org/mailman/listinfo/higgins-dev _______________________________________________ higgins-dev mailing list higgins-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/higgins-dev |