Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
GetRPAttributes Design Considerations
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}
STATUS: work in progress. Some random notes.
Design considerations
- Role tags are completely arbitrary. They are added, deleted etc. by the user. They may not even make sense.
- Role tags define personas (i.e. persona R1 is the set of all person nodes that have role = R1)
- There may be more than one role tag on a Person
- Different Persons have different sets of "used" and "instantiated" attributes
- Sometimes the "used" list is not available (either the person's context has a null h:control, or there is not "used" list in the h:control template context)
- We must return a consistent set of attribute values
- We may sacrifice coverage
Insights
- It is the caller's choice of roles that segment the requested attributes into N role-sets each of which may be supplied by a different p:Person
Consistency
- all attributes in the requested set that are reached from some path down from P share all common ancestral branch nodes instances (excepting the person node itself)
Examples...
The following are inconsistent (because a != b):
- attribute path #1: (p1 v:adr a) / (a v:street-address "123 Main")
- attribute path #2: (p1 v:adr b) / (b v:postal-code = "01010")
The folowing are consistent (because a == a):
- attribute path #1: (p1 v:adr a) / (a v:street-address "123 Main")
- attribute path #2: (p1 v:adr a) / (a v:postal-code = "02345")