Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  1. Open Actions
  2. Administrivia
    1. schacGender - Consultation status
      1. When we do a consultation, it should be for a new version of the spec, not for a specific topic. So we would send out SCHAC 1.6 with schacGender deprecated as the consultation.
      2. Next question is whether there is anything else in SCHAC that we would want to consider changing.  SEB to take some time between now and the next call to review the 1.5 spec and see if anything else is needed.
      3. Should there eventually be a grand-unified schema? Maybe a long term consideration? Consider adding an issue to GitHub.
        1. This should not be something that complicates the proposed consultation
  3. SCHAC request (see email to schema-discuss mailing list, 11 January 2022)
    1. urn:schac:personalUniqueID:{COUNTRY_CODE}:passport:{PASSPORT_CODE}. (Defined by each country)
      1. Given this is defined within the country, there is no concern about having this in a registration. How they were proposed in the email is substantively the same.
      2. Passport could legitimately be its own attribute, though then the question is what happens when you have more than one passport in one country. Since personalUniqueID is multivalued, this isn't a problem, either.
      3. Response to the email: urn:schac:personalUniqueID:int:passport:{COUNTRY_CODE}:{PASSPORT_CODE} with reference to
        •  Heather Flanagan the ldap schema for SCHAC 1.5 is outdated for links; need to make it match the PDF
  4. Membership
    1. Intro: Mark Rank
  5. Subcommittee status
    1. voPerson
      1. some traffic in the GitHub repository on doing a SCIM representation
      2. need to finish the formality of tagging v2; all substantive issues are resolved
    2. eduPersonDisplayPronoun
      1. Group held its first call; will produce two outputs: a proposal for a new attribute and a best practice doc
  6. Status of splitting the eduPerson spec into core and supplemental
    1. Splitting Protocols From Schema Documents (slightly revised)
      1. [KH] EduPerson attributes have now been incorporated into the draft Attribute Dictionary ( )
      2. Where would information on whether something is single or multi-valued be stored? In the protocol-specific documents (not the attribute dictionary). Other specs being defined in the future may want to consider when other protocols consider something single or multi-valued.
      3. What a thing is cannot be totally divorced from how it's used in different contexts; can we instead describe these things in a way that lends itself to translation, not entirely separate per protocol? The corresponding challenge is whether to stick with concrete, protocol-specific language in examples or rethink a whole metalanguage to describe everything
      4. This discussion started in part based on what voPerson did in terms of separating protocol profiles (see