highly-constrained ALPS profile vs. more generalized problem description ALPS profile.

constrained-alps.xml

<alps>
  <link rel="profile" href="https://gist.github.com/mamund/f5ad7ebf2aa0833ceb89" />
  <doc>
    An example of a highly-constrained ALPS profile. One that leaves very
    few choices to implementors. I don't recommend this kind of profile
    design since the aesthetics of ALPS is to create profiles that focus
    on the problem and allow creative people to design their own solutions
    with that problem space.  - @mamund
  </doc>
  
  <!-- data elements -->
  <descriptor id="givenName"  />
  <descriptor id="familyName" />
  <descriptor id="nickName" />
  <descriptor id="email" />
  <descriptor id="lastUpdated" />
  <descriptor id="statusMessage" />

  <!-- containers -->
  <descriptor id="fullUser">
    <descriptor href="#givenName" />
    <descriptor href="#familyName" />
    <descriptor href="#nickName" />
    <descriptor href="#email" />
  </descriptor>
  
  <descriptor id="listUser">
    <descriptor href="#nickName" />
  </descriptor>
  
  <descriptor id="briefUser">
    <descriptor href="#givenName" />
    <descriptor href="#familyName" />
  </descriptor>
  
  <descriptor id="createdUser">
    <descriptor href="#nickName" />
    <descriptor href="#statusMessage" />
  </descriptor>
  
  <descriptor id="updatedUser">
    <descriptor href="#fullUser" />
    <descriptor href="#lastUpdated" />
    <descriptor href="#statusMessage" />
  </descriptor>
  
  <descriptor id="deletedUser">
    <descriptor href="#statusMessage" />
  </descriptor>
  
  <descriptor id="searchUser">
    <descriptor href="#fullUser" />
    <descriptor href="#lastUpdated" />
  </descriptor>
  
  <descriptor id="editableUser">
    <descriptor href="#fullUser" />
    <descriptor id="userUpdate" type="idempotent" rt="#updatedUser">
      <descriptor href="#fullUser" />
    </descriptor>
    <descriptor id="userDelete" type="idempotent" rt="#deletedUser">
      <descriptor href="#nickName" />
    </descriptor>
  </descriptor>

  <!-- tranistions -->
  <descriptor id="userList" type="safe" rt="listUser">
    <descriptor id="filterByNickName" type="safe" rt="searchUser">
      <descriptor href="#nickname" />
    </descriptor>
    <descriptor id="filterByFamilyName" type="safe" rt="searchUser">
      <descriptor href="#familyName" />
    </descriptor>
    <descriptor id="filterByGivenName" type="safe" rt="searchUser">
      <descriptor href="#familyName" />
    </descriptor>
    <descriptor id="userRead" type="safe" rt="editableUser">
      <descriptor href="#nickName" />
    </descriptor>
    <descriptor id="userCreate" type="unsafe" rt="createdUser">
      <descriptor href="#editableUser" />
    </descriptor>
  </descriptor>
  
</alps>

problem-space-profile.xml

<alps>
  <link rel="profile" href="https://gist.github.com/mamund/f5ad7ebf2aa0833ceb89" />
  <doc>
    An example of a profile just defines the problem (data elements 
    and possible transitions) without specifying any nesting, order of
    events, or suggested arguments for transitions. All that information
    will be supplied to the client at runtime by the service's hypermedia
    messages. - @mamund
  </doc>
  
  <!-- data elements -->
  <descriptor id="givenName"  />
  <descriptor id="familyName" />
  <descriptor id="nickName" />
  <descriptor id="email" />
  <descriptor id="lastUpdated" />
  <descriptor id="statusMessage" />

  <!-- transitions -->
  <descriptor id="userList" rel="collection" />
  <descriptor id="userRead" rel="item" type="safe" />
  <descriptor id="userSearch" rel="search" type="safe" />
  <descriptor id="userUpdate" rel="edit" type="idempotent" />
  <descriptor id="userDelete" rel="http://alps.io/rels/delete" type="idempotent" />
  <descriptor id="userCreate" rel="http://alps.io/rels/create" type="unsafe" />

</alps>