Hi,
Thanks for the additional Information.
Here is what we are trying to accomplish.
We have several "sites" {Public, Local, National, Press, etc...} and wanted
to use separate workspaces for each one in order to segment the content.
However, occasionally, content from one "site" must refer to content from
another "site". If we implemented this using workspaces, a node from one
workspace will need to refer to a node from a different workspace.
Sounds like a "grouping" to me... ;)
I think the misconception (and misuse) of workspaces is one
of the most common issues around "Content Modeling" in general.
In the JCR Expert Group we found that we still have to explain
the very abstract concept of Workspaces much more in details and give
some best practices, guidelines and clear indications
on when to use workspaces.
I will try to give it a first shot here:
Workspaces are useful in combination with versioning or
cross-workspace operations (such as merge or update) that
means if you have nodes with the same UUID in various
workspaces it is likely that your usecase is valid.
In case you have no nodes with the same UUID in different
workspaces it is likely that you would be better served by "folders" (nodes
in the hierarchy), since the workspace also is the boundary for
references or query. There are a few usecases that desire this additional
isolation, but one has to be clear of the implications.
So to come back to your datamodel, I would recommend to do something
like: /content/public, /content/national, /content/local, ... This would for
example also allow you to search everything, which may or may not
be a desired sideffect.
Currently I can't see a drawback of modeling things into one workspace.
On a completely different note I would like to mention that (since WebCM is
our core business) I would also discourage the use of of (hard)-references
for almost every usecase in WCM. In WCM I think that dealing with a dangling
reference (in JCRv1.0 pretty much a string, containing a UUID) on an
application
layer is more desirable.
The additional overhead and constraint of the referential integrity on
a content layer
is constricting...
I would certainly be interested in continuing this discussion since I think
that good content modeling guidelines or recommendations are something
that we lack in JCR and the "content" space in general.
regards,
david
