Depends on whether we want to be able to perform calculations on dateOfBirth, for example to see if a user is over 18 (something which raises its head from time to time). The RESTful spec equivalent XSD date of the string below would be 1975-01-01. Luckily, this example string just happens to be unambiguous so I can parse it; I couldn't do that for 10/11/03 for example.
If we do want to have date of birth as an actual date and not a string, I think that means that epoch seconds are right out. Unless you want to ban everyone over age 38 from doing social networking :) John Panzer (http://abstractioneer.org) On Mon, Jun 30, 2008 at 12:53 PM, David Primmer <[EMAIL PROTECTED]> wrote: > I too am curious how the 'canonical' id will get specified. I'm > assuming Louis just 'punted' on this one for now. > > However regarding the dates: the dates that seem to matter are not in > the format that John mentioned. Updated and PostedTime matter. Can't > "dateOfBirth" : "1/1/1975", be an string? > > We definitely need to resolve the date format thing for these two > fields. Seconds since epoch or XSD Dates. > > Here's the RESTful spec: > Dates and timestamps are represented as strings containing AtomPub > (RFC3339) format date-time elements; see section 3.3 of [RFC4287]. > These are also known as "XSD Dates". In cases where only a > day-of-the-year is desired, e.g., a birthday, the year SHOULD be > specified as 0000. > > Which conflicts with the JS > A string specifying the time at which this activity took place in > milliseconds since the epoch. > > What is the ultimate storage format? > > davep > > On Mon, Jun 30, 2008 at 12:36 PM, John Panzer <[EMAIL PROTECTED]> wrote: > > LG, except for the human readable id strings like 'canonical', and that > the > > dates are in some unknown format (1/1/1999); would be good to document > the > > format or better yet use xsd dates. > > > > John Panzer (http://abstractioneer.org) > > > > On Mon, Jun 30, 2008 at 12:29 PM, Louis Ryan <[EMAIL PROTECTED]> wrote: > > > >> I've created a JIRA issue with a sample JSON DB patch attached here > >> > >> https://issues.apache.org/jira/browse/SHINDIG-413 > >> > >> There are definitely issues with some of the data that I will work on. I > >> will also ping on the RESTful discussion list to point folks at this > data > >> as > >> I think it makes sense to use the same data in the spec document and in > the > >> canonical DB. > >> > >> I am working on a driver for this structure and I should have a patch > ready > >> today > >> > >> On Fri, Jun 27, 2008 at 7:44 PM, Dan Peterson <[EMAIL PROTECTED]> > >> wrote: > >> > >> > Sounds great to me as well, looking forward to seeing it in the sample > >> > container. > >> > > >> > -Dan > >> > > >> > On Fri, Jun 27, 2008 at 5:45 PM, Kevin Brown <[EMAIL PROTECTED]> wrote: > >> > > >> > > That would be really useful for ensuring compatibility between PHP > and > >> > > Java. > >> > > It definitely beats the simple xml fetcher thing :) > >> > > > >> > > On Fri, Jun 27, 2008 at 5:29 PM, Louis Ryan <[EMAIL PROTECTED]> > wrote: > >> > > > >> > > > Hi, > >> > > > > >> > > > I would like to propose a canonical data implementation for use in > >> > > Shindig > >> > > > for unit and end-to-end testing based on a JSON structure that we > >> check > >> > > > into > >> > > > SCM. > >> > > > > >> > > > The idea is pretty simple, define a JSON structure that contains > the > >> > > > canonical data in the form described in the RESTful spec. > Something > >> > like > >> > > > > >> > > > { "people" : < an array of Person JSON objects>, > >> > > > "activities" : <an array of Activity JSON object for people>, > >> > > > "data" : <an array of app-data for people>, > >> > > > "friendLinks" : < a mapping between people id's to simulate > friend > >> > > links>, > >> > > > "dataLinks" : < a mapping between people id's and their app data> > >> > > > } > >> > > > > >> > > > This structure is loaded into a JSON DB driver and used to satisfy > >> > > service > >> > > > requests. The driver will support CRUD operations on activities > and > >> > data > >> > > in > >> > > > line with the spec. > >> > > > > >> > > > Advantages: > >> > > > - Fully exercises the JSON side of the RESTful spec and its > binding > >> to > >> > > > POJOs > >> > > > etc > >> > > > - Supports simple mutability > >> > > > - Its canonical! > >> > > > - Shared between all the implementations > >> > > > > >> > > > Im working on creating some data which Ill send out if folks are > >> > > interested > >> > > > > >> > > > -Louis > >> > > > > >> > > > >> > > >> > > >
