[Dev] Feedback on repository documents requested

[John Anderson]

I just looked at Ted's document and noticed that it does use parcel XML 
to document the repository -- so my comments below don't apply to his 
documentation -- I think Ted's document does a good job of addressing my 
concern and doesn't quite match my reading of Andi's comment.

I have two suggestions for Ted's document:

It would be useful to have a list of datatypes that the repository 
supports, with examples in parcel XML, with an eye to which datatypes 
map onto Python datatypes and which don't, and which Python datatypes 
can't be represented in the repository. Note common stumbling blocks, 
i.e. you can't mix references and literals in lists and dictionaries. 
Document the combinations of using the different types of cardinality. 
Document the difference between initial values, default values (now 
deprecated), no values, None values, empty lists, etc. would also help.

It would be useful to include more in depth discussion of single refs 
vs. bidirectional refs, how they are implemented and the consequences of 
using them.

I think it would be useful to put his document on the wiki (if it 
already isn't there) and continuing to make minor improvement after 0.4

John

John Anderson wrote:

> I think Andi is missing an important point a here:
>
> Almost all the use of the repository by real people today, and in the 
> foreseeable future, is via parcel XML and the a small amount of 
> repository API. Learning how to use the repository from the perspecive 
> of parcel XML is essential to learning the repository in real world 
> applications.
>
> I think it's unfortunate that we ended up with two different XML 
> formats, parcels and packs, which have a nearly idential purpose -- I 
> think they should have been combined, and if not, I think that parcel 
> XML belongs more to the repository than to Chandler, CPIA or any other 
> project.
>
> John
>
> Andi Vajda wrote:
>
>>
>>> 1) A general overview of how the repository fits in with the rest of 
>>> Chandler would be helpful. I think it's implicit in the doc that the 
>>> repository can be used separately and also as part of the Chandler 
>>> PIM. Would be clearer if this were made explicit. Thus, this doc 
>>> addresses both people who want to develop parcels on top of the 
>>> Chandler PIM and also parcels completely independent of the Chandler 
>>> PIM.
>>
>>
>>
>> Actually, developing parcels is a Chandler activity, the repository 
>> doesn't understand parcels, they are a funtionality introduced in a 
>> layer above the repository.
>>
>> Andi..
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Dev" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/dev
>
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev