Hello Ard, Tobías,
first of all, let me thank you for your answers. After reading
Tobías answer to rule #1 and then reading Ard's I realized that I may
have misunderstood the 'data vs. structure' thing, and thank you both
for your clarifications.
OTOH, my file node (extending nt:file) already has the lang as
metadata (a property). I'm doing tests both extending nt:file (1st
attempt) and nt:resource (as David suggests), I don't really find any
difference, though I know there may be some difference in performance,
or compatibility, I don't know...
I'll ponder the pros and cons of both approachs (folders vs. SNS)
and perform tests with both.
Thanks again for your prompt and accurate answers.
Tobias Bocanegra escribió:
> On 9/8/08, Ard Schrijvers <[EMAIL PROTECTED]> wrote:
>
>> Hello Fabián Mandelbaum,
>>
>> First of all, IMHO, you do not have to entirely commit to David's model.
>> IMHO, some of the rules are based on the frontend technology that is
>> displaying the data (like number 4, beware of same name siblings. When
>> creating frontends based on repository paths and cache them etc etc, I
>> understand same name siblings are nasty, but, AFAICS, it is a frontend
>> technology driven rule. Same holds for some other rules.)
>>
>> So, in your case, I would preferably not structure your content in folders
>> containing the 'language' name. As you said, you break one of Davids Rules
>> (though, again, creating some basic structure doesn't seem harmful to me at
>> all, again :-)) ), but worse, you might run into cumbersome queries
>> regarding performance. You probably will need to do all queries having some
>> path info, slowing queries significantly.
>>
>> I would create same name sibblings, and have meta data (a property) on the
>> file indicate the language. I must admit you might want to have some
>> features for this we have added on top of Jackrabbit, like 'filtered
>> mirrors': below some node, we expose a virtual copy of the repository,
>> filtered on some properties to only show those nodes you want to. All nodes
>> in this virtual layer are accessed jsr compliant, so, the client isn't even
>> aware (we call this a facetselect, a mirror with filters, where we also
>> expose facetsearches, a virtual facetted navigation within Jackrabbit, again
>> jsr compliant). Though even without this enhancement I would go for same
>> name sibblings and meta data. Querying on meta data is alsways fast, as
>> opposed to querying with path info.
>>
>
>
> the nice thing about not having SNS and having a folder structure for
> the language is that you can easily access it via webdav. so you just
> drop your translated files in the respective folder again, and your
> done. having SNS and meta data just renders this impossible.
>
> regards, toby
>
> ps: imo SNS were a stupid idea (the way they were speced in jcr1.0.
> there are some efforts in jsr283 to correct this) and are actually
> only valid to use when importing/exploding XML files into the
> repository. but you always have troubles as soon as you have SNS, and
> you need a lot of application logic to handle and use them
> efficiently.
>
>
>
>> Just my 2 cents,
>>
>> Regards Ard
>>
>>
>>
>> > Fabián Mandelbaum wrote:
>> > Approach #2 is indeed, natural, however the "problem" I see
>> > with approach #2 is that it seems to break David's rule #1
>> > (data 1st vs.
>> > structure 1st) by imposing a fixed content structure to
>> > projects (for example, /common/ /en/ /fr/ /es/ /it/ etc.).
>> >
>> > I'm not saying I won't end doing things this way (actually,
>> > it is so far my personal choice), I just wanted to know if
>> > there was a way to do it in a way that conforms a bit more to
>> > David's rule #1.
>> >
>> > Thanks again.
>> >
>> > Tobias Bocanegra escribió:
>> > > hi,
>> > > it certainly depends on your intention, but having a folder
>> > for each
>> > > language is imo the best approach. you might have other resources
>> > > later (like images) that are language dependent that you can put in
>> > > the folder.
>> > >
>> > > regards, toby
>> > >
>> > > On 9/6/08, Fabián Mandelbaum <[EMAIL PROTECTED]> wrote:
>> > >
>> > >> Hello there,
>> > >>
>> > >> I'm considering David's Model
>> > >> (http://wiki.apache.org/jackrabbit/DavidsModel) and was wondering
>> > >> how would David handle translations of documents.
>> > >>
>> > >> Let's say I have a file, for example: file.xml which
>> > is written
>> > >> in English, and I want to store its translation to, say, Spanish.
>> > >> Which would be the recommended storage model?
>> > >>
>> > >> 1) Common storage place
>> > >>
>> > >> /content/file.xml (English version)
>> > >> /content/file-es.xml (Spanish version)
>> > >> /content/file-fr.xml (French version)
>> > >>
>> > >> 2) Folders for each language
>> > >>
>> > >> /content/en/file.xml
>> > >> /content/es/file.xml
>> > >> /content/fr/file.xml
>> > >>
>> > >> 3) Workspaces for each language
>> > >>
>> > >> /content/file.xml (in 'en' workspace)
>> > >> /content/file.xml (in 'es' workspace)
>> > >> /content/file.xml (in 'fr' workspace)
>> > >>
>> > >> Other? My ears are open, Thanks in advance.
>> > >>
>> > >>
>> >
>> >
>>
>>
