I have a case where I think I've followed the XMLMERGE rules, but for reasons I can't figure out the merge is not happening and I'm ending up with two XML blocks when there should be just one merged one. The tenant configuration is: https://github.com/cherryhill/sdmom-tenant-config/blob/2f3f4d8ec422c16e45611a8c28083ed7a1faa259/application/sdmom-collectionobject.xml#L494-L499 ...and the merged configuration has these two blocks: https://gist.github.com/dltj/e3061fe845b58b2439ac#file-merged-base-collectionobject-at-dcd3137-xml-L777-L782 https://gist.github.com/dltj/e3061fe845b58b2439ac#file-merged-base-collectionobject-at-dcd3137-xml-L795-L801 The part that I find odd is another nearly identical XML block in the same <section> works: https://github.com/cherryhill/sdmom-tenant-config/blob/2f3f4d8ec422c16e45611a8c28083ed7a1faa259/application/sdmom-collectionobject.xml#L501-L507 Any ideas why this is happening? Peter -- Peter Murray Dev/Ops Lead and Project Manager Cherry Hill Company

Hi Peter, I think <repeat id="objectProductionPlaceGroupList/objectProductionPlaceGroup"> needs to go above <repeat id="objectProductionPeopleGroupList/objectProductionPeopleGroup"> in order to match the ordering in the base file. The merge doesn't work right if you reorder elements in the overlay. Ray On Tue, Jan 5, 2016 at 6:27 PM, Peter Murray <pmurray@chillco.com> wrote: > I have a case where I think I've followed the XMLMERGE rules, but for > reasons I can't figure out the merge is not happening and I'm ending up > with two XML blocks when there should be just one merged one. The tenant > configuration is: > > > https://github.com/cherryhill/sdmom-tenant-config/blob/2f3f4d8ec422c16e45611a8c28083ed7a1faa259/application/sdmom-collectionobject.xml#L494-L499 > > ...and the merged configuration has these two blocks: > > > https://gist.github.com/dltj/e3061fe845b58b2439ac#file-merged-base-collectionobject-at-dcd3137-xml-L777-L782 > > > https://gist.github.com/dltj/e3061fe845b58b2439ac#file-merged-base-collectionobject-at-dcd3137-xml-L795-L801 > > The part that I find odd is another nearly identical XML block in the same > <section> works: > > > https://github.com/cherryhill/sdmom-tenant-config/blob/2f3f4d8ec422c16e45611a8c28083ed7a1faa259/application/sdmom-collectionobject.xml#L501-L507 > > Any ideas why this is happening? > > > Peter > -- > Peter Murray > Dev/Ops Lead and Project Manager > Cherry Hill Company > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >

Oh, nuts. Okay, that makes sense. I'm falling into the trap of thinking of the merge files as some sort of XSLT where order doesn't matter. (Which, of course, it isn't.) Can this be reinforced in the documentation somewhere? I tried to find a good place to put this tip on [Merging your changes into CollectionSpace's Application layer - Unreleased Current Documentation - CollectionSpace](https://wiki.collectionspace.org/display/UNRELEASED/Merging+your+changes+into+CollectionSpace%27s+Application+layer), but the way the content on that page is structured doesn't lend itself to adding a statement about ensuring the order of XML elements matches what is in the base file. Peter > On Jan 6, 2016, at 1:09 AM, Ray Lee <rhlee@berkeley.edu> wrote: > > Hi Peter, > I think > > <repeat id="objectProductionPlaceGroupList/objectProductionPlaceGroup"> > > needs to go above > > <repeat id="objectProductionPeopleGroupList/objectProductionPeopleGroup"> > > in order to match the ordering in the base file. The merge doesn't work right if you reorder elements in the overlay. > > Ray > > On Tue, Jan 5, 2016 at 6:27 PM, Peter Murray <pmurray@chillco.com <mailto:pmurray@chillco.com>> wrote: > I have a case where I think I've followed the XMLMERGE rules, but for reasons I can't figure out the merge is not happening and I'm ending up with two XML blocks when there should be just one merged one. The tenant configuration is: > > https://github.com/cherryhill/sdmom-tenant-config/blob/2f3f4d8ec422c16e45611a8c28083ed7a1faa259/application/sdmom-collectionobject.xml#L494-L499 <https://github.com/cherryhill/sdmom-tenant-config/blob/2f3f4d8ec422c16e45611a8c28083ed7a1faa259/application/sdmom-collectionobject.xml#L494-L499> > > ...and the merged configuration has these two blocks: > > https://gist.github.com/dltj/e3061fe845b58b2439ac#file-merged-base-collectionobject-at-dcd3137-xml-L777-L782 <https://gist.github.com/dltj/e3061fe845b58b2439ac#file-merged-base-collectionobject-at-dcd3137-xml-L777-L782> > > https://gist.github.com/dltj/e3061fe845b58b2439ac#file-merged-base-collectionobject-at-dcd3137-xml-L795-L801 <https://gist.github.com/dltj/e3061fe845b58b2439ac#file-merged-base-collectionobject-at-dcd3137-xml-L795-L801> > > The part that I find odd is another nearly identical XML block in the same <section> works: > > https://github.com/cherryhill/sdmom-tenant-config/blob/2f3f4d8ec422c16e45611a8c28083ed7a1faa259/application/sdmom-collectionobject.xml#L501-L507 <https://github.com/cherryhill/sdmom-tenant-config/blob/2f3f4d8ec422c16e45611a8c28083ed7a1faa259/application/sdmom-collectionobject.xml#L501-L507> > > Any ideas why this is happening? > > > Peter -- Peter Murray Dev/Ops Lead and Project Manager Cherry Hill Company

Hi Peter, I'll see if we can work that into one or more of the Docs, including the page you mentioned, in some sensible way. The ordering sensitivity of the merge files does clearly need to be reinforced. Like you, I'd originally assumed that these were ordering insensitive. Postscript: it turns out there's an existing JIRA for that work: https://issues.collectionspace.org/browse/CSPACE-6720 Aron P.S. Thanks much, Ray, for responding to Peter on this. On Wed, Jan 6, 2016 at 7:05 AM, Peter Murray <pmurray@chillco.com> wrote: > Oh, nuts. Okay, that makes sense. I'm falling into the trap of thinking > of the merge files as some sort of XSLT where order doesn't matter. > (Which, of course, it isn't.) > > Can this be reinforced in the documentation somewhere? I tried to find a > good place to put this tip on [Merging your changes into CollectionSpace's > Application layer - Unreleased Current Documentation - CollectionSpace]( > https://wiki.collectionspace.org/display/UNRELEASED/Merging+your+changes+into+CollectionSpace%27s+Application+layer), > but the way the content on that page is structured doesn't lend itself to > adding a statement about ensuring the order of XML elements matches what is > in the base file. > > > Peter > > > On Jan 6, 2016, at 1:09 AM, Ray Lee <rhlee@berkeley.edu> wrote: > > Hi Peter, > I think > > <repeat id="objectProductionPlaceGroupList/objectProductionPlaceGroup"> > > needs to go above > > <repeat id="objectProductionPeopleGroupList/objectProductionPeopleGroup"> > > in order to match the ordering in the base file. The merge doesn't work > right if you reorder elements in the overlay. > > Ray > > On Tue, Jan 5, 2016 at 6:27 PM, Peter Murray <pmurray@chillco.com> wrote: > >> I have a case where I think I've followed the XMLMERGE rules, but for >> reasons I can't figure out the merge is not happening and I'm ending up >> with two XML blocks when there should be just one merged one. The tenant >> configuration is: >> >> >> https://github.com/cherryhill/sdmom-tenant-config/blob/2f3f4d8ec422c16e45611a8c28083ed7a1faa259/application/sdmom-collectionobject.xml#L494-L499 >> >> ...and the merged configuration has these two blocks: >> >> >> https://gist.github.com/dltj/e3061fe845b58b2439ac#file-merged-base-collectionobject-at-dcd3137-xml-L777-L782 >> >> >> https://gist.github.com/dltj/e3061fe845b58b2439ac#file-merged-base-collectionobject-at-dcd3137-xml-L795-L801 >> >> The part that I find odd is another nearly identical XML block in the >> same <section> works: >> >> >> https://github.com/cherryhill/sdmom-tenant-config/blob/2f3f4d8ec422c16e45611a8c28083ed7a1faa259/application/sdmom-collectionobject.xml#L501-L507 >> >> Any ideas why this is happening? >> >> >> Peter > > > > -- > Peter Murray > Dev/Ops Lead and Project Manager > Cherry Hill Company > > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > >