Person Identification Service Avatar
  1. OMG Specification

Person Identification Service — Closed Issues

  • Acronym: PIDS
  • Issues Count: 4
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Descriptions

The IDL contained in the PIDS specification is not CORBA compliant

  • Key: PIDS11-34
  • Legacy Issue Number: 3859
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The IDL contained in the PIDS specification is not CORBA compliant.

    Specifically, the declarations

    struct TaggedProfile

    { PersonId id; Profile profile; }

    ;

    and

    struct TraitSelector

    { Trait trait; float weight; }

    ;

    fail to comply with the rule that the semantics of OMG IDL forbids identifiers in the same scope to differ only in case.

    The PIDS IDL will compile under the OrbixWeb ORB, but it fails to compile under ORBacus unless the --case-sensitive option (which is not CORBA compliant) is used.

  • Reported: PIDS 1.0 — Fri, 15 Sep 2000 04:00 GMT
  • Disposition: Resolved — PIDS 1.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:50 GMT

"RequiredTraits" exception issue

  • Key: PIDS11-33
  • Legacy Issue Number: 3789
  • Status: closed  
  • Source: Level Seven Visualizations ( Jon Farmer)
  • Summary:

    he "RequiredTraits" exception returns a sequence of traits. But
    make_ids_permenant takes an ARRAY
    of input ids. So this exception if thrown won't provide any usefull
    information as to which id
    had the problem.

    Our implementation, rather than throwing the exception, just creates the ID
    in a temporary state. However, as we recently considered supporting the
    exception in conjunction with a probabilistic matching algorithm, we found
    the following ambiguity:

    The RequiredTraits exception inlcudes a list of required traits, but the
    spec doesn't clarify that this is the complete list of required traits -
    assuming that its the same set for any input profile - so that the client
    can figure out which IDs need for traits.

    The problem with that semantic is as follows. Some probabilisitc matching
    algorithms can only determine the adequacy of the incoming trait set by
    inspecting the VALUES of the trait types supplied. for example, if the
    incoming request tries to register two ids, one with first=John ,
    Last=Smith, and the second with First=Mergetroid Last=Pepperdyne, a
    probabilisitc algorithm will likely accept the second but reject the first;
    YET BOTH supplied the same traits. Hwo could the client figure out what's
    missing? How the server even figure out what's missing? Neither can. ONLY
    THE ALGORITHM KNOWS....... AND IT ONLY KNOWS ONCE IT HAS SEEN THE INPUTS.

    Therefore we need to define clearly what the exception semantics are, and in
    a way that doesn't preclude the use of probabilistic matchers that cannot
    assess adequacy in a "one trait list fits all" manner.

    One possible solution is to have the exception return a SEQUENCE OF
    offending ids - so the client can know which are offensive. Instead of also
    including for each the set of traits needed, the return structure could show
    the confidence deficit for each.

  • Reported: PIDS 1.0 — Thu, 10 Aug 2000 04:00 GMT
  • Disposition: Resolved — PIDS 1.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:50 GMT

${issue.summary}

  • Key: PIDS11-32
  • Legacy Issue Number: 2750
  • Status: closed  
  • Source: Anonymous
  • Summary:
  • Reported: PIDS 1.0 — Thu, 17 Jun 1999 04:00 GMT
  • Disposition: Resolved — PIDS 1.1
  • Disposition Summary:

    closed

  • Updated: Fri, 6 Mar 2015 20:50 GMT

Extended Cleanup of Description of QoS Properties

  • Key: PIDS11-31
  • Legacy Issue Number: 2744
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The issue author enumerates several points of confusion with

    regard to the applicability of QoS properties to specific objects

    within a channel. The issues are as follows:

    1) Setting Priority or Timeout on a ConsumerAdmin or ProxySupplier

    is meaningless, and should be disallowed

    2) StartTimeSupport and StopTimeSupported on a ProxyConsumer or

    SupplierAdmin is meaningless, and should be disallowed

    3) OrderPolicy (like DiscardPolicy) on a ProxyConsumer or

    SupplierAdmin is meaningless, and should be disallowed

    4) MaximumBatchSize and PacingInterval are meaningless for Any

    and Structured Event style Proxies

    The issue author goes onto suggest that Table 2-4 should add

    specific columns for each style of Proxy, so that the applicability

    of QoS properties to specific objects can be designated with finer

    granularity.

  • Reported: PIDS 1.0 — Wed, 16 Jun 1999 04:00 GMT
  • Disposition: Resolved — PIDS 1.1
  • Disposition Summary:

    fixed, see below

  • Updated: Fri, 6 Mar 2015 20:50 GMT