Skip to main content
Jump to: navigation, search

Difference between revisions of "Context Data Model 1.1 Open Issues"

(Open Issues)
(No difference)

Revision as of 18:54, 4 March 2008

Open Issues

  1. Need a replacement term for "Node".
    • Most higgins developers don't like it.
    • We've had a vote and "Entity" won
    • We're trying to get a telecon together to close this issue
  2. Can we represent closed (non-mixed) types in OWL so that the LDAP CP can represent its schema?
  3. Ability to declare user-defined Classes to be 'closed', that is instances of them should follow the class definition, but not include any other "extra" properties. (same as previous?)
  4. This entire wiki page: HOWL is out of date with the rest of this wiki
  5. Closed or open simple data types
    • Paul asserts that we have the ability already to specify a format constraint along with a data type. For example, one could say the data type of an attribute is normalizedString, but constrained to a pattern that looks like a telephone number
    • We can do this by creating a Data Range. A Data Range has a base XML Schema type (e.g. string) as well as all of the XML Schema facets (e.g. pattern, etc.)
  6. Worth noting somewhere: Node Relations are only an abstract super-types for real, useful relations like "memberOf", "reportsTo", "friend". Or "hasFavoriteBook", "hasCreditCard", etc.
  7. Tony: We don't have a simplified description of the data model
    • Need a simple-to-follow set of pictures that explain the data model
    • This PPT was updated to the latest concepts terms and improved a bit based on feedback from the Jan/Provo F2F: Higgins Data Model Intro.PPT

Resolved Issues

  1. Mixed attribute value data types
    1. Daniel points out that it would still be good to pass type on each value add:
      2. (and follow-ups)
    2. Resolution: we can mix types.
  2. Can an attribute have mixed values consisting of both simple and complex?
    1. Resolution: Yes.
  3. Many same-types attributes
    2. Resolution: No. (We should document that this isn't allowed/possible)
  4. Allow zero-valued attributes
    2. Resolution: we should not allow zero-valued attributes in the model per se. It is true that for access control reasons, no value will be returned in some cases.

LDAP-specific Issues

See Also

Back to the top