Difference between revisions of "ContextId"

Revision as of 00:30, 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>

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

Do we need a method in IdAS to test that two given ContextRefs actually resolve to the same Context?

@@ Line 14: / Line 14: @@
 ==Open issues==
-# 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)?
-# Do we assume all URIs that use the HTTP scheme are resolvable? (URLs)
-# 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)
 # Do we need a method in IdAS to test that two given ContextRefs actually resolve to the same [[Context]]?