how validate record ?

Hi Benoit! Thanks for the question, I'm sorry it took so long to notice it was here. I'm asking someone working on desktopcouch to take a look and provide some more information.

Re-opening as I have not answered the question.

We have no schemas yet. python-couchdb schemas will not work for us, because of mergeable lists[*], which are uuid-keyed dictionaries, designed to make possible semi-intelligent conflict resolution of merges with complex collection types (i.e. JSON lists of non atomic types). We will look into extending python-couchdb schemas with a new field type, or if that is not possible, creating our own validation schemas.

[*] for instance, something like:

            "addresses": {
                    "e47455fb-da05-481e-a2c7-88f14d5cc163": {
                        "street_address": "Kalverstraat 1",
                        "city": "Amsterdam",
                        "type": "home"},
                    "d6d2c23b-279c-45c8-afb2-ec84ee7c81c3": {
                        "street_address": "Champs Elysées 1",
                        "city": "Paris",
                        "type": "work"}},

In this case, the uuid fieldnames are of course not predictable, and we can't capture them in a schema directly, so we need some way of indicating a dictionary field that has any number of fields with uuid-like keys, and whose values are of a specific form.

i wasn't thinking to a couchdb-python schema type. More on a way to know that city is a string, a date , a date ... Like I undrstand here we have a lits of adress type. Each adress has its own uuid. So if I understand each kind of data have its own uuid in one document. having a way to self describe these types whatever the language you use in your app could help. Something like relax ng maybe ?

Well, I'd prefer to reuse existing code to building our own schema language, (a hard problem, unless there is a schema language with validation in existance for JSON?) which is why I looked at python-couchdb first. (Which does let you specify the leaf node types as integer/date/string etc. I believe.)

Each type of data does not have it's own uuid. Perhaps a more realistic example is useful:

{
   "_id": "62d27539a9bb7af3d7fe33aea8b0b045",
   "_rev": "2-765105cf557b703b47d1393d713ee8a8",
   "first_name": "myFirstName",
   "last_name": "myLastName",
   "addresses": {
       "e84fde3e-4a7a-4997-8108-1353353bf0ce": {
           "city": "myWorkCity",
           "description": "work",
           "address1": "1 myWorkStreet",
           "state": "myWorkState",
           "country": "myWorkCountry",
           "postalcode": "myWorkPostalCode"
       },
       "_order": [
           "e84fde3e-4a7a-4997-8108-1353353bf0ce",
           "fabdddf7-490c-4c42-bb11-dceaea578668",
           "d76bf1d1-db68-457f-978b-6c7c8f029831"
       ],
       "d76bf1d1-db68-457f-978b-6c7c8f029831": {
           "city": "myOtherCity",
           "description": "other",
           "country": "myOtherCountry",
           "state": "myOtherState",
           "address1": "1 myOtherStreet",
           "postalcode": "myOtherPostalCode"
       },
       "fabdddf7-490c-4c42-bb11-dceaea578668": {
           "city": "myHomeCity",
           "description": "home",
           "address1": "1 myHomeStreet",
           "state": "myHomeState",
           "country": "myHomeCountry",
           "postalcode": "myHomePostalCode"
       }
   },
   "record_type": "http://api.ubuntuone.com/schema/contact/0.1",
   "birth_date": "1971-01-01",
   "phone_numbers": {
       "00b10d79-cf9e-459b-bbb1-3a01727114ed": {
           "description": "home",
           "number": "myHomePhone"
       },
       "3d56e68f-c314-43bf-8020-58f7682065b6": {
           "description": "mobile",
           "number": "myMobilePhone"
       },
       "385a6cde-8877-4863-b1d7-8e592c7f0d47": {
           "description": "home fax",
           "number": "myHomeFax"
       },
       "09bce785-eb6a-49e3-bab3-a63e7565b6ae": {
           "description": "work",
           "number": "myWorkPhone"
       },
       "58aef0cf-22cc-4b6c-9354-3612113b8cf4": {
           "description": "car",
           "number": "123"
       },
       "_order": [
           "58aef0cf-22cc-4b6c-9354-3612113b8cf4",
           "00b10d79-cf9e-459b-bbb1-3a01727114ed",
           "ef94b639-aca6-4558-babe-8b9656298a1f",
           "3d56e68f-c314-43bf-8020-58f7682065b6",
           "385a6cde-8877-4863-b1d7-8e592c7f0d47",
           "cdfbbeb1-ec74-4d61-82e5-a0a7d1a16663",
           "58d89f0b-de73-4193-8119-f1445afc1db9",
           "09bce785-eb6a-49e3-bab3-a63e7565b6ae"
       ],
       "cdfbbeb1-ec74-4d61-82e5-a0a7d1a16663": {
           "description": "radio",
           "number": "345"
       },
       "58d89f0b-de73-4193-8119-f1445afc1db9": {
           "description": "pager",
           "number": "myPager"
       },
       "ef94b639-aca6-4558-babe-8b9656298a1f": {
           "description": "work fax",
           "number": "myWorkFax"
       }
   },
   "email_addresses": {
       "1716f4d1-7482-40c7-9f97-3f7b561e4c34": {
           "description": "work",
           "address": "<email address hidden>"
       },
       "_order": [
           "cc198316-4f87-431f-8b20-a73a30de7b69",
           "1716f4d1-7482-40c7-9f97-3f7b561e4c34",
           "1459bf35-129e-43fc-b2cd-c20ffa69850f"
       ],
       "1459bf35-129e-43fc-b2cd-c20ffa69850f": {
           "description": "other",
           "address": "<email address hidden>"
       },
       "cc198316-4f87-431f-8b20-a73a30de7b69": {
           "description": "home",
           "address": "<email address hidden>"
       }
   }
}

As you can see, uuids are used to denote unique "instances" of complex (i.e. dictionary) values in a list such as addresses, email addresses, phone numbers. The python code in desktopcouch mostly hides this complexity from the client developer, and lets them treat these as regular lists, while keeping the uuid keys underwater, so that client-side manipulations to sub values, and reordering can be detected as such.

http://www.json.com/json-schema-proposal/ might be a useful thing for someone to look at here.

Yes it could be a good start. But how too integrate it with record ? I think it would be really good to have something working independantly of the languages.

It will allow for example to have app using python but also be on top of couch via couchapps or more. Having some kind on dtd when you point on http://api.ubuntuone.com/schema/contact/0.1 will help a lot to check what is the base schema and what to add as note.

I agree, but I'd like to involve everyone currently interested in desktopcouch in coming up with the best possible way to do this. I think the desktopcouch mailing list is the best place to continue this discussion. I will kick it off by giving a short introduction and referencing this page, but I would greatly appreciate if you giving your input there as well.

People from the future, view or join that mailing list here: http://groups.google.com/group/desktop-couchdb

s/giving/gave/

relevant thread: http://groups.google.com/group/desktop-couchdb/browse_thread/thread/b131ce4f0571d843#