[Cps4] cps/jcr document mapping

[Eric Barroca]

On 7 avr. 06, at 16:04, Florent Guillaume wrote:

> On 7 Apr 2006, at 15:51, Eric Barroca wrote:
>> On 7 avr. 06, at 15:04, Florent Guillaume wrote:
>>
>>> On 6 Apr 2006, at 19:23, Bogdan Stefanescu wrote:
>>>> It's ok from Apogee point of view.. in fact we have no requirements
>>>> about the model  implementation.
>>>> Apogee should be able to adapt itself to any type of repository  
>>>> model -
>>>> so we only need to know exactly how the cps model will be  
>>>> structured to
>>>> be able to implement adapters to plug it into Apogee
>>> Ok, the point is really that we want to be as "natural" as  
>>> possible for the JCR, so that a plugin to a non-CPS JCR would be  
>>> nearly the same.
>> I don't think there is a natural way for the data model. There is  
>> an efficient way and that's what we are looking for.
>> Apogée won't be an "JCR" browser, so it has to implement all  
>> features needed by CPS like understand the security model,  
>> flexible schemas, content form, etc.
>> I would like to avoid focus on the *natural*. I prefer the  
>> efficient way :-)
>>
>>
>> On flexible parts of a data schemas, how do you plan to store it ?  
>> As child nodes ?
>
> There won't be flexible schemas anymore.
>
> Instead there will be list properties holding for instance the list  
> of attached files (maybe empty).
> If we have specific layout requirements, for instance a specific  
> order to display:
>   - attached file 1
>   - attached file 2
>   - paragraph of text 1
>   - attached file 3
>   - paragraph of text 2
> Then we'll have a specific additional "layout" field deciding of  
> this order. In addition to the list of files and the list of  
> paragraphs.
I does not answer the current need we have : managing optional  
complex data blocks.
The order is not really important. The major point is : I want to add  
a data block with 2 text fields, 1 attached file and 2 date and is  
considered as only one block.

> Another way feasible in the JCR would be to have ordered child  
> nodes (properties are never ordered) for flexible attributes, but  
> that's quite different from existing CPS schemas. I haven't thought  
> about that yet...
We need to manage it with childnodes (like node type  
cps:contentfragment).

In fact, it's the exact use case of supporting XSD ComplexTypes.

For schemas management, are we still considering to use XSD? I think  
this approach need ot be kept.


A+

EB.

--
Éric Barroca - Tel: +33 6 21 74 77 64 (mobile).
Nuxeo - Open Source ECM - www.nuxeo.com
CPS Platform - The open source ECM Platform
http://cps-project.org - http://www.nuxeo.com/en/cps