Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "ContextId"

(Open issues)
Line 1: Line 1:
A ContextRef is a URI that identifies a [[Context]].
+
* A [[ContextRef]] is a URI that identifies a [[Context]].
* ContextRefs are used by the [[Identity Attribute Service (IdAS)]] and by [[Context Provider|Context Providers]]
+
* [[ContextRef]]s either directly or indirectly (e.g. by conventions, lookups, etc.) provide sufficient information to identify a [[Context]]  
* ContextRefs either directly or indirectly (e.g. by conventions, lookups, etc.) provide sufficient information to identify a [[Context]]
+
* Two different [[ContextRef]]s may refer to the same [[Context]]
* A given ContextRef may be used against multiple [[Context Provider|Context Providers]] to produce the same [[Context]] (although different IContext instances).
+
* If two [[ContextRef]]s are equal, they refer to the same Context dataset, although not necessarily the same [[Context]] "container" instance
 +
* ContextRefs are used by the [[Identity Attribute Service (IdAS)]] and by [[Context Provider]]s
 +
* A given [[ContextRef]] may be used against multiple [[Context Provider]]s to produce the same [[Context]] (although, as mentioned, different IContext instances).
 
* ContextRefs MAY be XRIs
 
* ContextRefs MAY be XRIs
 
* ContextRefs MUST be subdivideable by "/" (e.g. to allow constructing through the following possible kind of concatenation: <contextRef-root>/<schemaType>/<object-identifier>
 
* ContextRefs MUST be subdivideable by "/" (e.g. to allow constructing through the following possible kind of concatenation: <contextRef-root>/<schemaType>/<object-identifier>
 
  
 
==Examples==
 
==Examples==

Revision as of 00:22, 9 December 2006

  • A ContextRef is a URI that identifies a Context.
  • ContextRefs either directly or indirectly (e.g. by conventions, lookups, etc.) provide sufficient information to identify a Context
  • Two different ContextRefs may refer to the same Context
  • If two ContextRefs are equal, they refer to the same Context dataset, although not necessarily the same Context "container" instance
  • ContextRefs are used by the Identity Attribute Service (IdAS) and by Context Providers
  • A given ContextRef may be used against multiple Context Providers to produce the same Context (although, as mentioned, different IContext instances).
  • ContextRefs MAY be XRIs
  • ContextRefs MUST be subdivideable by "/" (e.g. to allow constructing through the following possible kind of concatenation: <contextRef-root>/<schemaType>/<object-identifier>

Examples

  1. http://www.fabrikam123.example/4f544/ldap347/HR/employees --an LDAP employee directory
  2. proprietary-scheme-a://contactlist -- user's contact list stored as tab-delimited file
  3. xri://foo*bar/baz

Open issues

  1. Context providers are in some cases (i.e. cases where the provider is creating a new Context and associated ContextRef) the generators/assigners of new ContextRefs. Should we allow them to assign their own schemes if they use proprietary technology (as in "proprietary-scheme-a" in #2 above)?
  2. Do we assume all URIs that use the HTTP scheme are resolvable? (URLs)
  3. Beyond resolvable, should we require as Tony has suggested that all HTTP-scheme URIs are also WS-Addressing endpoint references? (This would solve the problem of how a provider could get the policy and other metadata to help it try to open and access the context data)
  4. Do we need a method in IdAS to test that two given ContextRefs actually resolve to the same Context?

Back to the top