Meeting Notes -- 28 Aug 2003

What

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

When & Where

• Thursday 28 Aug 2003 -- 4:00 - 5:30
• OSAF office in San Francisco

Who attended

• BrianDouglasSkinner
• AndiVajda
• KatieCappsParlante

Agenda going in

• Start working 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)

• agenda items
  • display name
    • <displayAttribute>, <label>, <name>
    • have Repository Viewer use displayAttribute?
  • terminology
    • issues:
      • singular vs. plural, in schema xml format vs. CoreSchema.xml
      • capitalization of kinds and attributes?
    • goal: get these components in sync
      • schema xml tags
      • CoreSchema.xml attribute definitions
      • repository API
  • full reflection
    • get all of CoreSchema.xml showing up in Repository Viewer
      • <relationshipType>, <Alias>, etc.
  • conceptual issues
    • non-global attribute definitions?
    • how to have kinds that "override" attribute definitions?
  • proposed features
    • <Alias>, <aliasFor>
    • multiple <type> values for an <AttributeDefinition>
    • missing <inverseAttribue> tags
    • <unidirectional>
    • <relationshipType>
    • <EnumKind>, <element>
  • open issues
    • relationship between path, URI, and xml namespace?

Resolutions coming out

• identifier names
  • In the DomainSchema.xml files, we have entries like.... <Attribute id="book:authors">
  • For attributes like this, we will use the attribute id-name "authors" in four different places. All these things will always be in sync; they won't have different names:
    • the "identifier name" of the Attribute item, as accessed through the python repository API
    • the repository containment path of the Attribute item
    • the xml element name for xml files that specify individual items, like... <book:authors>Pat Clarke<book:authors>
    • the python attribute name for the python class used when loading items of this kind (e.g. foo = Book.authors)

• capitalization
  • we will use CapWords for the names of Kinds, like "Book" and "Person"
  • we will use mixedCase for the names of chandler attributes, like "title", "authors", and "lastName"
  • we will use mixedCase for the names of python attributes, like "currentSortOrder"

• singular vs. plural
  • multi-valued attributes (list, set, dict) will have identifier names like "examples", not "example", even though this means that some xml files will look slightly weird, with lines like... <book:authors>Pat Clarke<book:authors>

• terminology
  • we will use the following terms
    • "displayName" (replaces "label" and "DisplayName")
    • "displayAttribute" (as currently used)
    • "defaultValue" (replaces "default" and "Default")
    • "description" (replaces "comment")
    • "cardinality" (replaces "Cardinality")
    • <classes key="python"> (replaces "pythonClass" and "Class")
    • "attributes" (replaces "attribute" and "AttrDef")
    • "Attribute" (replaces "AttributeDefinition" and "AttrDef")
    • "Enumeration" (replaces "Enum")
    • "inverseAttribute"
    • "otherName" (derived from "inverseAttribute"?)
    • "superKinds"
    • "subKinds"
    • "superAttribute"
    • "subAttributes"

• to be continued...

Open issues

• terminology
  • more terminology issues
    • "Anything" as alias for ("Item" or "Literal")
    • "name" -> ??? ("id", or "idName", or "identifierName", or "tag" or...???)
    • "derivation" vs. "derivationRule" vs. "InheritFrom" ???
    • "DomainSchema" vs. "schema" ???
    • "itemref" vs. "reference" vs. "ref" ???
    • "dict" vs. "set" ???
    • "Duration" vs. "DateTimeDelta" ???
    • "Datetime" as alias (for "FlexibleDatetime" or "RigidDatetime")
    • "FlexibleDatetime" vs. "RelativeDateTime" ???
    • "RigidDatetime" vs. "DateTime" ???
    • "Enumeration" for heavyweight enums vs. "Enumeration" for lightweight enums
    • "RepositoryContainmentPath" vs. "Path" ???
    • "RepositoryContainmentParent" vs. "parent" ???
    • "UnicodeString" vs. "String" ???
    • "Taxon"?
    • "relationshipType"?
    • others? ... (e.g. Alias, aliasFor, hidden, abstract, required, unidirectional)

• full reflection
  • strive to get all of CoreSchema.xml showing up in Repository Viewer?
    • <relationshipType>, <Alias>, etc.

• 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

• sub-attribute issues
  • non-global attribute definitions?
  • how to have kinds that "override" attribute definitions?

• proposed features
  • <Alias>, <aliasFor>
  • multiple <type> values for an <AttributeDefinition>
  • missing <inverseAttribue> tags
  • <unidirectional>
  • <relationshipType>
  • <EnumKind>, <element>

• 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
    • the

• 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?

• 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 - 28 Aug 2003