Dear PSC members,
Here is a proposal to allow propagation for parent changes to all children [1].
A patch is attached to the proposal.
Looking forward to your votes,
Cheers,
Mathieu
Hi Mathieu,
+1 and nice work!
Another suggestion which I reckon you would have already considered (but I'll say it anyway :-)): I would like to see (once we have the composed records capability in trunk) an option that the user running the update could select to create XLinks in the children to the parent record elements as opposed to actually replacing or adding content. I realize that GeoNetwork would be storing records composed of XLinks to fragments rather than 'valid ISO records' as XLinks are only allowed on some ISO elements but this doesn't matter if the record is composed when read from the db and its going to happen anyway with the capability to have records with harvested fragments of metadata. In short, the update-child-with-parent-elements function would become yet another way of building composed metadata records. Any thoughts?
(I'll have to get the composed records proposal up for voting.)
Cheers and thanks,
Simon
Mathieu Coudert wrote:
Dear PSC members,
Here is a proposal to allow propagation for parent changes to all children [1].
A patch is attached to the proposal.
Looking forward to your votes,
Cheers,
Mathieu[1] UpdateChildren – GeoNetwork opensource Developer website
------------------------------------------------------------------------------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
------------------------------------------------------------------------_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
+1 for me.
2010/4/2 Simon Pigot <Simon.Pigot@anonymised.com>:
Hi Mathieu,
+1 and nice work!
Another suggestion which I reckon you would have already considered (but
I'll say it anyway :-)): I would like to see (once we have the composed
records capability in trunk) an option that the user running the update
could select to create XLinks in the children to the parent record
elements as opposed to actually replacing or adding content. I realize
that GeoNetwork would be storing records composed of XLinks to fragments
rather than 'valid ISO records' as XLinks are only allowed on some ISO
elements but this doesn't matter if the record is composed when read
from the db and its going to happen anyway with the capability to have
records with harvested fragments of metadata. In short, the
update-child-with-parent-elements function would become yet another way
of building composed metadata records. Any thoughts?
Yep true Simon, composed children records based on XLink from parent
could be a good option.
One point which need some work probably is to trigger cache cleaning
on updates of the parent (this as been investigated by Jesse on the
reusable objects I think in geocat.ch sandbox).
(I'll have to get the composed records proposal up for voting.)
I've been using the updated XLink resolver from the bluenet sandbox to
handle XLinks for keywords and contacts with good success. I was
wandering how do you manage XLink one the editor in composed metadata
record. Maybe we could talk about that on IRC some days ?
Ciao.
Francois
Cheers and thanks,
SimonMathieu Coudert wrote:
Dear PSC members,
Here is a proposal to allow propagation for parent changes to all
children [1].A patch is attached to the proposal.
Looking forward to your votes,
Cheers,
Mathieu[1] http://trac.osgeo.org/geonetwork/wiki/UpdateChildren
------------------------------------------------------------------------------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
------------------------------------------------------------------------_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Hi Simon,
On Fri, Apr 2, 2010 at 3:21 AM, Simon Pigot <Simon.Pigot@anonymised.com> wrote:
Hi Mathieu,
+1 and nice work!
Another suggestion which I reckon you would have already considered (but I’ll say it anyway :-)): I would like to see (once we have the composed records capability in trunk) an option that the user running the update could select to create XLinks in the children to the parent record elements as opposed to actually replacing or adding content. I realize that GeoNetwork would be storing records composed of XLinks to fragments rather than ‘valid ISO records’ as XLinks are only allowed on some ISO elements but this doesn’t matter if the record is composed when read from the db and its going to happen anyway with the capability to have records with harvested fragments of metadata. In short, the update-child-with-parent-elements function would become yet another way of building composed metadata records. Any thoughts?
I agree with you Simon, this option could be added at a later stage, once we will have the composed records capability in trunk.
As François said, this will result to side effects and improvements which will need to be achieve at this point…
For now, I’m gonna commit it in its current stage as I received enough vote to set it into trunk! 
(I’ll have to get the composed records proposal up for voting.)
Good news!
Cheers,
Mathieu