r9 - 26 Dec 2003 - 14:09:04 - DuckySherwoodYou are here: OSAF > Jungle Web > DataModelJunglePages > DataModelSept2003FeatureList
September 2003 Data Model Feature List and Issues List
Here's a summary of the features we're talking about having in the data model, and the open issues we still need to resolve, as of September 2003.Features
The features listed below will be available to parcel developers who are creating new domain-specific schemas, and to end-users who are editing Chandler items or creating domain-specific schemas. Most of the features listed below are here because they have some impact on the data model itself. Some of the features may not directly impact the data model, but we've included them here anyway because of their impact on Chandler's end-to-end data handling infrastructure.Top Five Features
Here's the short list of the most interesting features of the Chandler data model.-
items, attributes, and kinds
- ad hoc attributes, and ad hoc items
- global attributes
- sub-attributes
- bi-directional references
Contents
- queries
- attributes
- restrictions
- ad hoc attributes
- references
- null values
- default values
- data types
- strings
- kinds and inheritance
- associating behavior with kinds
- item versioning
- sharing
- schemas
- repositories
- deletion and garbage collection
- reflection
- derivation
- RDF
- names and namespaces
- authorization
- files and attachements
- notifications
- undo and transactions
Table of Features and Issues
| resolved: "in" features Features we've already implemented, or that we've resolved to implement. | resolved: "out" features Features we've resolved not to implement. (The Chandler platform won't have first-class support for this feature, but third-party parcels might offer this feature, built on top of Chandler building blocks.) | open issues Features that we haven't yet made a decision about. | |
| queries # |
queries represented as a query data structure (e.g. query items)
queries can be saved and used again later
|
 no built-in support for queries that span multiple repositories
no built-in support queries that span foreign data sources (like IMAP)
|
 queries represented as strings
what sorts of queries?
|
| attributes # |
sub-attributes -- like in RDF
global attributes -- attributes can be defined globally (like in RDF), or for a kind
aliases -- users can set attributes to be vague types like "Number", "AnyString", "Anything"
cardinalities -- 'single' and 'list' for both literals and references, plus 'dict' for literals
attributes flagged as ones to index on
|
no compound attributes -- attributes can have component attributes (name: first_name, last_name)
no attributes bound to a kind (non-global)
no attributes that describe sentences (as opposed to attributes that describe items)
|
whether or not we deal with types and kinds as being homogeneous and interchangable
|
| restrictions # |
cardinality restrictions
non-null restrictions (required/optional)
data type restrictions (e.g. "Float") -- strong typing available, and weak typing available
|
no multi-valued type restrictions (e.g. "Integer or String")
|
range restrictions (e.g. "21 to 35")
inter-attribute restrictions
transitive restrictions
"expectations" vs. restrictions
|
| ad hoc attributes # |
ad hoc attributes that hold a single literal value
|
multi-valued ad hoc attributes (list, dict)
ad hoc values that are item references rather than literals
ad hoc attributes implemented as references to ad hoc Attribute items (e.g. so that they can have a display name)
|
|
| references # |
bi-directional references between items (but only within a repository)
both weak-reference and strong-reference relationships (but only within a repository)
references across repositories (only unidirectional weak-references)
'referencePolicy', as well as 'copyPolicy' and 'deletePolicy'
cardinalities -- 'single', 'list' -- effectively supporting 1-to-1, 1-to-Many, and Many-to-Many relationships
|
no bi-directional references across repositories
no strong-references across repositories
|
how we handle reference policies (e.g. wholly-owned items)
unidirectional referenences
cross-repository references -- foreign items, local proxies, and partial proxies
reference policies -- can we have referencePolicy use inheritFrom to get deletePolicy and copyPolicy?
|
| null values # |
attributes with null values
items with missing attributes (as distinct from attributes with null values)
|
||
| default values # |
default values can be specified for an attribute
default values are set when attribute is created, not when an item is created, or on get()
|
||
| data types # |
both strong-typing and weak-typing for attributes (e.g. "float" vs. "Anything")
UUIDs -- 128-bit ids, unique across all repositories
basic data types -- Integer, Float, Boolean, etc.
|
additional data types -- URL, file, Blob...
timezones, and different types of dates and times
lightweight enums (an enumeration of symbols) vs. heavyweight enums (an enumeration of items) -- mappings between lightweight enums and heavyweight enums
hierarchical enums |
|
| strings # |
'Symbol' as a basic type (ASCII, no spaces, etc.) -- (available at system level, but not user level)
unicode strings -- 'String' as a basic type (16-bit unicode strings) -- all strings in unicode, not ASCII
platform independent rich text strings
standard display string attribute ("displayName")
kind-specific display string attributes ("displayAttribute")
HTML links in strings
"StringWithItems" -- strings with bi-directional chandler links
"PolyglotString " -- dictionary of localizations keyed by language
|
whether or not we support PolyglotString as a literal vs. an Item
whether or not we support StringWithItems as a literal vs. an Item
"AnyString" -- whether or not we have "AnyString" as alias for String, PolyglotString, and StringWithItems (strings with Chandler bi-directional references)
recognisers that recognise strings as items
"promoting" strings to items
attributes that can be either a string or an item (e.g. "String" or "Task")
|
|
| kinds and inheritance # |
multiple inheritance (for kinds)
single-kind items (an item can be a "primary instance" of just one kind)
multi-kind items (an item can have a list of "secondary kinds" -- for example, e-mail messages that are also tasks)
item morphing -- an item can change from one kind to another, but only if it does not have associated Python parcel code
"type" inheritance -- an item of a sub-kind counts as being of the type of the super-kind
"attribute" inheritance -- a sub-kind inherits the attributes from the super-kind
|
no items becoming instances of a kind as a result of automatic ontology reasoning
|
|
| associating behavior with kinds # |
kinds can have associated python classes
|
no kinds with any sort of associated behavior other than via their python class associations
|
|
| item versioning # |
versioning features can be implemented by custom app code
|
no built-in support for versioning -- no DB-level support for item versions
no past versions of items
no change objects
|
|
| sharing # |
replicated items -- local copies of items from other repositories
|
what kind of support for publishing and subscription -- how to implement automatic updates for subscriptions?
cross-repository references
local copies and proxies
|
|
| schemas # |
how does one schema add attributes to a kind defined in another schema?
user customization of the PIM schema
schema evolution in a multi-user shared-repository environment
sharing items across different schemas
|
||
| repositories # |
repository subsets (DataModelIssues#Repository_Subsets)
virtual repositories (within a server repository, my repository vs. your repository)
|
||
| deletion and garbage collection # |
simple garbage collection mechanism similar to ref-counting
explicit deletion of items
|
||
| reflection # |
full reflection -- schema info as first class items -- items for Kinds, Types, Aliases, and Attributes
third parties can create new Types, Aliases, Kinds, and Items
|
||
| derivation # |
attribute inheritance -- via the 'inheritFrom' attribute
|
no derivation rules -- on kinds or on instances
no indexing of derived values
no derived items (e.g. recurring events)
|
flagging an attribute as a derived attributes, without any further special handling
hooks that allow custom Python code to implement derived attributes
|
| RDF # |
import/export in Chandler-centric RDF format (bare-bones, and PIM ignorant)
|
import/export domain specific RDF formats (e.g. Calendar)
mappings to other RDF schemas
|
semantic dictionaries for mappings
|
| names and namespaces # |
XML schema files that use namespaces
|
non-global attribute definitions (bound to a kind)
|
where we want to use references by name vs. bi-directional item references (e.g. otherName vs. inverseAttribute)
relationship between URLs, itemPaths, XML schema file namespaces, Chandler's notion of namespaces, and DomainSchemas
|
| authorization # |
users, accounts, permissions, groups
relationship between Kinds used for authorization (users, permissions, groups) and Kinds used in the PIM schema (users, personas, profiles, groups, contacts, agents)
item-level vs. attribute-level permissions (partial-item permissions)
capabilities vs. ACLs -- other issues
group permissions
kind-instantiation permissions
permissions for domain attributes vs. house-keeping attributes
|
||
| files and attachements # |
imported files vs. file bookmarks
e-mail attachements
"in-repository" storage vs. references to file-system files
|
||
| notifications # |
some form of simple notifications
|
what sort of notifications?
conditions?
triggers?
|
|
| undo and transactions # |
some form of transactions
|
rollback
undo implemented based on transactions
|
- for more background info see the issues descriptions on these pages:
Contributors
- BrianDouglasSkinner - 15 Sep 2003 to 28 Sep 2003
Log In
Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.
See list of page contributors for attributions.