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.
Difference between revisions of "GetRPAttributes Design Considerations"
(→Design considerations) |
(→Design considerations) |
||
| Line 9: | Line 9: | ||
* Different Persons have different sets of "used" and "instantiated" attributes | * 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) | * 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 must return a '''consistent''' set of attribute values |
* We may sacrifice coverage | * We may sacrifice coverage | ||
Revision as of 18:28, 15 November 2010
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}
STATUS: work in progress. Some random notes.
Contents
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
Previously unstated (undocumented!) constraint on p:Persons
- every link is in a different dimension
- multiple values are only allowed on leaf attributes
- any subset of a p:Person's attributes must be logically consistent
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)
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")
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")