Meeting Notes -- 29 Aug 2003

What

• Data Model -- sync up CoreSchema.xml with repository code

When & Where

• Thursday 29 Aug 2003 -- 11:00 - 5:00
• OSAF office in San Francisco

Who attended

• BrianDouglasSkinner
• AndiVajda
• KatieCappsParlante by phone

Agenda going in

• Work on bringing different data-handling components into sync with each other:
  • the CoreSchema.xml file
  • the repository API
  • the new schema XML format
  • the DomainSchemaLoader code
  • the repository viewer parcel
  • the schema of schemas xml files (pack and item files)

Resolutions coming out

• terminology
  • we will use the following terms
    • "itemParent" (replaces "parent")
    • "itemChildren" (replaces "children")
    • "itemPath" (replaces "path")
    • "itemName" (replaces "name" in the repository, and replaces "id" in the schema xml)
    • "derivationNotes" (replaces "derivation")
    • "inheritFrom" (replaces "InheritFrom")
    • "itemref" (remains as is in the schema xml format)
    • "DomainSchema" (remains as is)
    • "referencePolicy" (replaces "relationshipType")
    • "setAttributeValue" (replaces "setAttribute")
    • "getAttributeValue" (replaces "getAttribute")
    • "getAttribute" (replaces "getAttrDef")
    • "Enumeration" (replaces "Enum")
    • "hidden"
    • "abstract"
    • "required"

• single valued "type"
  • the "type" Attribute will have cardinality "single", although the single value can be an Alias that allows multiple types

• required inverseAttribute
  • Attributes that are references are required to have an inverseAttribute. We won't support "implied" inverseAttributes.

• Anything
  • "Anything" as an alias that points to nothing and allows any item or literal value
  • the Attribute "type" has a default value of "Anything"

• Cardinalities
  • we will support four cardinalities: 'single', 'list', 'dict', and 'set'
  • we will support 'set' for both sets of literals and sets of references

• String Types
  • we will add "Symbol" as one of the basic types available
  • we will use the name "String" for the basic Unicode string type
  • we will have aliases like "AnyString" and "HTMLString" that represent trhe notion of different sorts of strings, although for now those aliases will all just point to "String"

• Taxon
  • we will have a kind called "Taxon" that will be the superkind for Kind, Type, and Alias

• referencePolicy
  • the referencePolicy attribute will have values that can be used to derive the values for the deletePolicy and copyPolicy, if we want to do that
  • the repository code will pay attention only to deletePolicy and copyPolicy
  • in the repository, the referencePolicy attribute will serve only as documentation, not as something that actually drives policy

• derivation rules
  • we resolved that the repository would not directly support derivation rules or derived attributes, although the python class corresponding to a Kind might implement its own derivation code to fill in attribute values

• unidirectional
  • For now, we're going to get rid of the "unidirectional" element in the xml schema file. Right now we don't want to offer any support for unidirectional references, although we might want to introduce the idea later if we think it's needed.

• full reflection
  • we're going to strive to get all of CoreSchema.xml showing up in Repository Viewer

• non-global attribute definitions
  • We won't support the idea of a non-global attribute definition as something that's fundamentally different from a normal global attribute definition. However, we might introduce some simple boolean flag that allows a schema author to mark some attributes as being conceptually non-global, and tools for doing schema viewing/editing could filter those out so they don't clutter up the list of interesting attributes.

Open issues

• derivation mechanisms
  • even though the repository will not directly support derivation rules or derived attributes, we might want to have some minimal sort of hook mechanism that would at least allow a schema author to flag an attribute as being derived, and allow the python class corresponding to a Kind to have special get and set methods to calculate values and set attributes

• OtherName vs. inverseAttribute
  • Our concept of inverseAttribute is slightly different from our concept of OtherName. We need to think more about what we really want, and then reconcile these two notions.
  • how to have kinds that "override" attribute definitions?

• Datetime
  • Brian proposes that "Datetime" be an alias for any sort of date time, including a "RigidDatetime" tpe (implemented using python DateTime) and a "FlexibleDatetime" type (implemented using python RelativeDatetime). Brian also proposes that the current "DateTimeDelta" type be named "Duration". Katie is going to think about what we really want in terms of datetime types, and then make a recommendation.

• support for heavyweight enums
  • What sort of support will we have for 'heavyweight' enums (meaning an enumeration where each possible value is a first-class item)?

• mapping from lightweight enums to heavyweight enums
  • What sort of support will we have for using lightweight enum strings as keys that point into a dictionary of corresponding heavyweight enum items? For example, using language codes like 'en' as an index for language items that have polyglot display strings with values like 'English', or using currency codes like 'usd' as an index into currency items that have display formats and attributes for name ('US Dollar') and symbol ('$').

• paths and namespaces
  • what relationship, if any, between:
    • the repository containment path
    • the URI
    • the xml namespace used in the schema file

• heterogenious collections, with both literals and ItemRefs
  • The implementation is difficult, but this may be an important feature. Should we support this feature or not?

• strings
  • polyglot strings -- Is a polyglot string a literal or an item?
  • strong typing for various string types -- What should a schema author be able to specify about a string:
    • single-line vs. multi-line (with tabs and line feeds)
    • HTML rich text vs. plain text
    • python-symbol vs. unrestricted text
    • HTML with links vs. without links
    • with Chandler ItemRef links vs. without links
    • with links based on values of attributes in the current item, vs. "freeform" links to any item

• ad-hoc attribute definitions
  • A generic item, with no associated Kind, can have ad-hoc attributes. Some of those attributes might be pre-defined, like the 'start time' attribute used by the 'Calendar Event' Kind. Other attributes will be brand new, and only used by that one item. Do we have Attribute Definition items in both cases?

---

-- BrianDouglasSkinner - 04 Sep 2003