- Work to support the 0.4 release
- respond to content model change requests that come up as people are doing work during 0.4
- sharing features
- Need to define content model for Principals, Certificates, Groups, and Permissions -- see UsersAndGroupsDesign
- Need to somehow model the notion of the "me" contact.
- need to use the sharingPolicy, just like deletePolicy and copyPolicy
- {source: ted 26 Feb 2004} We need to go through the content model and address some of the issues raised by the query examples. Ted will work with Katie to make sure that this happens.
- Need to sort out the content model for collections, item collections, explicit collections
- Each "content item" needs to have not just a list of the "item collections" that it's in, but also a primary "default collection"
- model for Parcels and Capplets
- {source: mitch 12 Feb 2004} In ChandlerLandscapeIssueFeb11, Mitch suggests a new take on Parcels and Capplets and where different Kinds are defined. We need to sign off on this, and then refactor the content model to reflect it.
- {source: mitch 17 Feb 2004} We need to define the content model for "capplets" (and maybe also parcels). See UnfiledDesign2004#ThirdPartyCapplets
- {source: mitch 19 Feb 2004} Need to define content model for parcels and capplets (see Capplet Design Doc). On a component by component basis, specify what's shared between capplets and what's done per-capplet: side bar, bookmark bar, nav bar, menu bar, etc.
- need to figure out how in the model we represent which attributes show up in which columns of a view
- {source: mitch 12 Feb 2004} In ZeroPointFourProposal, we say that "Meeting organizer, Requestor AND Invitees, Requestee will map to From AND To" -- we need to look at the content model and make a proposal about how to do this
- Think about moving "Who", "About", and "Date" off of Content Item and over to somewhere else.
- {source: john 4 Mar 2004} Need to figure out how we want to model stamping -- see DesignGroupMeeting20040304
- {source: mitch 22 Apr 2004} add data model and content model support for ad-hoc attributes (or decide not to) -- see DataModelSept2003FeatureList
- as we reach resolutions for issues like how to model derived attributes and other open issues in the data model, update the content model to reflect the current data model design
- have a 0.4 design review for the content model, to surface content model issues
- send mail to dev list requesting design review
- have the 0.4 content model support CPIA
- "Investment" work -- spend a little time now to prevent headaches later
- Start on the Sample Data Project -- Come up with a standard sample data set to use in tests, in design sessions, etc.
- Continue work on the Content Model Interoperation Project
- After we have a better understanding of how we're planning to use date and time types, we should look at all the DateTime attributes and think about whether they should really be RelativeDateTimes
- Look at iCalendar enough to identify and understand any major issues. Make sures there's a reasonable mapping between Chandler and iCalendar.
- Need a good name for the concept (and the kind) that represents something that can be either a task, or an event, or both. Also need to validate that this idea is really compatible with the way iCalendar does things.
- Bug#1149 -- full pass at modeling dates, times, durations, and timezones
- date/time/timezone issues,
- startTime/endTime/duration
- all day events, multiple day events
- Bug#1149 -- full pass at modeling calendar parcel, including
- Reminder and RecurrencePattern
- Bug#1148 -- add AnyContact to the contact parcel -- AnyContact will be an Alias for EmailAddress, Contact and String. It can be used as a type for such attributes as "creator", "participants", any attribute where conceptually a person might be represented by their email address, contact entry, or a simple identifying string (name, etc.)
- once we understand what data model features are available for structs, figure out whether to use structs for 'Conversations'
- Once we understand what data model feature are available, clean up the content model to use those features. Do this for:
- String vs. Single-line-string
- see Katie's dev list post
- see comment from MikeT below -- "Message Header - it's listed as a single string, would a list of strings be more appropriate?"
- plain-text-string vs. rich-text-string
- strings and text fields that include links to Chandler items
- flexible dates: Jan 14, Feb 2005, "all day on 13 May 2004"
- timezones
- what data type for the email attribute "Polling Frequency" -- duration?
- binary/blob?
- reference type "owns" == delete policy + copy policy
- references should have a "sharing policy", similar to "delete policy" and "copy policy" -- see ItemLinksAndSharing
- {mimi 12 Jan 2004} maybe change the attribute "hidden" (boolean) to be "visibility" (enum: visible, hidden, invisible)
- We also need to get the design group to sign off on all the displayNames, and then think about whether we want to bring the itemNames into sync with the displayNames. The names of the Kinds are fairly well vetted, bu most of the attribute names should be scrutinized. Ideally it would be good to pick attribute names that (1) are the words that end-users would use, (2) match the vCard and iCalendar standard names, (3) match what Outlook and Palm use, and (4) are short.
- {source: mitch 23 Feb 2004} We need to go through the existing content model and think about which kinds belong in the "Chandler core". We should refactor the content model and pick a good separation between (a) Chandler core content model and (b) PIM content model. -- see table in UsersAndGroupsDesign2004#ContentModelLayers. We need to think about What kinds should be included in the Chandler core? Mitch suggests we consider these kinds:
- File -- a Chandler item that has an attribute that points to an old-fashioned file in the OS file system, like a spreadsheet file or a MS Word doc
- Conversation -- a Chandler "Conversation" item, attached to a Content Item
- Note
- Contact
- Mail Message
- IM
- The current model for Contact Name is heavily U.S. centric. Should we replace what we have with the vCard standard attribute names like "Family Name" and "Given Name" instead of "Last Name" and "First Name"?
- Cleanup work
- We need to walk through all the parcel.xml files, and make sure each attribute is in the right file. I think some attributes aren't really where we want them.
- The attributes description, examples, and issues are currently attributes of Item. We should think about moving them to be attributes of Taxon and Parcel.
- {source: mitch Dec 2003} go through the list of open issues that appear on the summary pages in the documentaion generated from the parcel.xml files. Prioritize the open issues and decide on order and march through the list resolving the issues.
- minor glitches
- I think we've now done a good first pass at getting the most important attributes into the parcel.xml file, and setting their type, cardinality, and inverseAttribute aspect values. Now we need to go through and set some values for other aspects
- required
- hidden -- we may want to make this an Enum instead of a Boolean?
- defaultValue -- maybe this should really be initialValue?
- Need to revisit the notion of the "fyiLinks" attribute on Content Item. Current thinking seems to be that we should delete this.
- once we know what data model features are available for inverseAttribute vs. otherName, need to go through the content model and clean it up
- once we have clear data model features for defaultValue vs. initialValue, clean up the content model using those features
- Other content model work
- We might look at the mapping to RDF as well.
- {source: mitch 23 Feb 2004} We need to think about What kinds should be included in the Chandler core? Mitch suggests we consider these kinds:
- File -- a Chandler item that has an attribute that points to an old-fashioned file in the OS file system, like a spreadsheet file or a MS Word doc
- We should see if there are any public documents about the PIM schema in Longhorn, and we should look into what it would take to make our schema interoperate smoothly with the Longhorn PIM schema. We might want to sign up for an MSDN membership to stay informed about Longhorn plans.
- content model for mail
- {source: mitch 12 Feb 2004} On Mail Message, we need some kind of a status attribute that has values like "sent", "draft", and "outgoing, but hasn't been sent yet". See also the existing Mail Message status attribute, and the embrionic "serverStatus" and "deliveryStatus" strings.
- {source: mitch 12 Feb 2004} On Mail Message, there should be an attribute that points to an IMAP folder on the IMAP server -- so that we can interoperate with IMAP adequately without having a folder structure that identically mirrors the IMAP folder structure. Note that the IMAP folders may be nested, so our attribute needs to be able to accomodate that.
- {source: MikeT 7 Mar 2004} Need to resolve issues about how to model Mail Message features -- character encoding, read receipt, message header, hasBeenRead and Status -- see comment below
- {source: mitch 13 Jan 2004} in Task/Event, have the body be just a special ("default"/"primary") contained note
- {source: mimi 12 Jan 2004} have different sorts of contacts -- allow different clumps of attributes to show up for different contacts -- e.g. soccer friends have a "jersey #", and people from work have a "department" and boss.
- review old 2002 OSAF PIM schema, and make sure there's nothing there that we should be harvesting -- if not, then mark those pages as obsolete
- {source: katie 8 Mar 2004} have the contacts content model be able to represent the fact that people's names sometimes change -- be able to keep track of past names -- most common case is probably maiden names
- think through what the data model needs to do to support internationalization (e.g. polyglot strings vs. parcel display-name overlays vs. other options)
- Data Model work
- figure out what the data model offers in the way of defaultValue vs. initialValue
- figure out what the data model offers in the way of inverseAttribute vs. otherName
- figure out what features we're supporting with structs, and whether structs should be used for 'Conversations'
- finish up different data model types for strings
- String vs. Single-line-string
- see Katie's dev list post
- see comment from MikeT below -- "Message Header - it's listed as a single string, would a list of strings be more appropriate?"
- plain-text-string vs. rich-text-string
- strings and text fields that include links to Chandler items
- finish up different data model types for dates
- flexible dates: Jan 14, Feb 2005, "all day on 13 May 2004"
- timezones
- duration -- what data type for the email attribute "Polling Frequency" -- duration?
- finish up data model type for binary/blob
- have core schema know about binary/blob?
- have data model offer a few more 'policy' primatives
- reference type "owns" == delete policy + copy policy
- references should have a "sharing policy", similar to "delete policy" and "copy policy" -- see ItemLinksAndSharing
- {mimi 12 Jan 2004} maybe change the attribute "hidden" (boolean) to be "visibility" (enum: visible, hidden, invisible)
|
Log In