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 explicit (e.g. role parameters to the attribute URI) or implicit (i.e. fixed role parameters of the attribute's associated mapping rule) role values that serve to segment the set of 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")

Trying to figure out if we must have the following constraint on p:Person nodes

• Every attribute (simple or complex) 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

Links

• PDS_Client_2.0_JavaScript_API