hi guys, i would rather stay away from all that business and just let the application handle it. it is important to understand that for versioning jcr does not have the concept of a head version but the concept of a node in that particular workspace. so different people can already have different views on the same content just using different workspaces.
the cases where someone wants to view or diff special versions in my can easily be delegated to the application and in my mind does not need to be a first level concept in sling. i would really like to stay away from all the locale since i find that i would not even like to model that on to the individual resource in my applications, since i want the tree to diverge in different locales. i think that our url processing is complicated enough and i would really like to delegate everything beyond what we have now to the application, until we find a usecase that is not served well by delegating this kind of functionality to the application. regards, david On 12/12/07, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > On Dec 12, 2007 6:27 PM, Juan José Vázquez Delgado > <[EMAIL PROTECTED]> wrote: > > > ...it´s more natural for me to have > > > > /content/some/resource.html/version1/lang1 > > than > > /content/mytext.a4.print.s:version:1:4.s:locale:fr_CH.html > > ... > > I agree that your suggestion looks nicer (also because you have > simpler values that might not reflect reality ;-), and that means we > don't "invade" the selectors space which is good. > > I'd still like to define a syntax to differentiate suffixes that are > handled by Sling/microsling, as opposed to suffixes used by > applications. > > How about > > /content/some/resource.html/s:version:1.4/s:lang:fr/somefile.pdf > > where suffixes starting with s: are reserved for Sling usage? > > -Bertrand >
