Thanks Heather, Aron, Jesse, and Rick for your work on getting this documentation sorted. One question for you all: As I was talking with Joe S. last week, he mentioned that he was trying to figure out where to put the WAC local schema. Is there a designated place, for example, where the local schema lives? Is that something that we cover in the documentation? Thanks, Angela On Sep 19, 2011, at 7:58 PM, Heather Hart wrote: > Hi Aron, > > Can you take a look at the updated multivalued field 1.8 pages and > add in the necessary details about the minibuild? > > http://wiki.collectionspace.org/display/CSPACE18/How+to+make+a+field+multivalued > > Also a general review for accuracy as of 1.8 would be great. Rick > has given it a once over already. > > Thanks, > Heather > > -----Original Message----- > From: Aron Roberts [mailto:aronroberts@gmail.com] > Sent: Thursday, September 15, 2011 3:51 PM > To: Jesse Martinez; Heather Hart > Cc: CollectionSpace Talk List > Subject: Re: [Talk] changed / deprecated links in 1.8 docs > > *******PLEASE READ before 'mirroring' any docs******* > > Many of the key v1.8 docs are very different than their v1.9 > counterparts: > > * Some of the Installing CollectionSpace docs for v1.8 are (at > least) slightly different than their 1.9 counterparts. > > * At least one or two of the core Configuring CollectionSpace docs > differ substantially from their 1.9 counterparts, to reflect that > the app layer configuration changed to a new overlay structure in > v1.9. > > Before doing any wholesale 'mirroring', it might be good to check a > chronological list of recently updated documents, and/or review > which documents should not be mirrored with both me and Kasper. > > Thanks, > Aron > > On Thu, Sep 15, 2011 at 3:08 PM, Jesse Martinez <jmartinez@movingimage.us > > wrote: >> Heather, >> I think it's safe to mirror 1.9 onto 1.8 documentation granted that >> we >> be aware of any recent changes to 1.9. Although, I make the >> assumption >> that some changes may have occurred on both 1.8 as well as 1.9 so in >> that case it's moot. The trouble with links is a big one and if we >> can >> straighten it with 1.9 then we'd all be better off since we'll use >> 1.9 for 1.11 and so on. >> We just need to make the concerted effort to follow every lin on >> every >> page to make sure it's pointing in the right location. >> I'm not aware of any time out issues for me/us on the east coast. Was >> this recently? Did you also see issues with jira or any of our >> other services? >> - Jesse >> >> On Thu, Sep 15, 2011 at 3:26 PM, Heather Hart <hhart@bpoc.org> wrote: >>> >>> Hi Joe, >>> >>> One documentation issue always leads to several dozen more. This is >>> really two separate problems. >>> >>> First of all, these pages were not copied over because at the time >>> the 1.8 wiki was mirrored from UNRELEASED, we had not yet rescued >>> these pages from the main wiki where they were buried. If you look >>> at >>> the 1.9 wiki space, these pages have been moved over and appear in >>> the heirarchy (left sidebar) under the appropriate page. >>> >>> Secondly, even though the pages exist where they should in the 1.9 >>> wiki, the links are still broken. The links did not travel well >>> because they are hard-linked (it is linked as a standard hyperlink: >>> http://wiki.collectionspace.org/display/collectionspace/How+to >>> +change >>> +the+definition+of+a+field+in+the+Services+configuration) >>> so when we "rescued" these pages, it also broke these links. >>> Unfortunately, the fluid tools can't tell us (as far as I know) >>> when we break hard links. >>> This is a great reminder to everyone to use the fluid tools when >>> editing the wiki pages. In this particular case, there is a child >>> pages macro that would work perfectly. Under normal circumstances it >>> is best to link to another cspace wiki page by using the search >>> function on the edit link screen. >>> >>> So, in terms of what we can and should do, the 1.8 wiki is in pretty >>> bad shape in general. Jesse, what do you think about re-mirroring >>> the >>> 1.9 wiki into 1.8? This is risky if people have been making >>> changes to the 1.8 pages. >>> The 1.9 wiki will include the "rescued" pages, but would not include >>> the fruits of our most recent documentation push (much of which may >>> apply to 1.8?). >>> >>> For now I am going to manually move these pages back into 1.8 and >>> then use the child macro instead of the hard-coded list so Joe can >>> continue his work. >>> I am having a bit of a time with this, since I keep getting >>> connection errors and "error retrieving breadcrumbs" problems. Is >>> anyone else having trouble with the wiki? >>> >>> Heather >>> ________________________________________ >>> From: talk-bounces@lists.collectionspace.org >>> [talk-bounces@lists.collectionspace.org] on behalf of Joe Slag >>> [joe@slagwerks.com] >>> Sent: Wednesday, September 14, 2011 8:10 AM >>> To: CollectionSpace Talk List >>> Subject: [Talk] changed / deprecated links in 1.8 docs >>> >>> I was just referring to >>> >>> http://wiki.collectionspace.org/display/CSPACE18/How+to+make+a >>> +field+ >>> multivalued and noticed that many of the details, under the heading >>> "Procedure step checklist", are links to pages that have been moved >>> or deprectated. >>> >>> For example, >>> http://wiki.collectionspace.org/display/collectionspace/How+to+edit >>> +t >>> he+definition+of+data+passed+into+and+out+of+a+field+in+the+UI >>> +schema >>> +file is linked to in step 2b. The top of that page says in red: >>> >>> REMOVE THIS PAGE - IT IS NOT ACCURATE. (FIELDS ARE NOT EDITED VIA >>> THE UI SCHEMA FILE) >>> >>> Many of the other pages seem to have been moved in a way that allows >>> confluence to make a good guess about their location, but still >>> presents an intermediate 'page moved' page. >>> >>> If this was just any old release I don't think it would be that >>> important, but I thought I'd mention it given 1.8's positioning as a >>> thoroughly-QA'd release. Also it might be nice to identify whatever >>> process problems led to this problem so that it can be avoided for >>> future releases. >>> >>> cheers, >>> Joe >>> >>> _______________________________________________ >>> Talk mailing list >>> Talk@lists.collectionspace.org >>> >>> http://lists.collectionspace.org/mailman/listinfo/ >>> talk_lists.collecti >>> onspace.org >> >> >> _______________________________________________ >> Talk mailing list >> Talk@lists.collectionspace.org >> http://lists.collectionspace.org/mailman/listinfo/ >> talk_lists.collectio >> nspace.org >> >> > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

We have been talking about this, but have yet to put together a good spot for this. I.e., it is on my plate which means it may wait a little... > -----Original Message----- > From: talk-bounces@lists.collectionspace.org > [mailto:talk-bounces@lists.collectionspace.org] On Behalf Of > Angela Spinazze > Sent: Tuesday, September 20, 2011 9:26 AM > To: Heather Hart > Cc: CollectionSpace Talk List > Subject: Re: [Talk] changed / deprecated links in 1.8 docs > > Thanks Heather, Aron, Jesse, and Rick for your work on > getting this documentation sorted. > > One question for you all: As I was talking with Joe S. last > week, he mentioned that he was trying to figure out where to > put the WAC local schema. Is there a designated place, for > example, where the local schema lives? Is that something > that we cover in the documentation? > > Thanks, > > Angela > > On Sep 19, 2011, at 7:58 PM, Heather Hart wrote: > > > Hi Aron, > > > > Can you take a look at the updated multivalued field 1.8 > pages and add > > in the necessary details about the minibuild? > > > > > http://wiki.collectionspace.org/display/CSPACE18/How+to+make+a+field+m > > ultivalued > > > > Also a general review for accuracy as of 1.8 would be > great. Rick has > > given it a once over already. > > > > Thanks, > > Heather > > > > -----Original Message----- > > From: Aron Roberts [mailto:aronroberts@gmail.com] > > Sent: Thursday, September 15, 2011 3:51 PM > > To: Jesse Martinez; Heather Hart > > Cc: CollectionSpace Talk List > > Subject: Re: [Talk] changed / deprecated links in 1.8 docs > > > > *******PLEASE READ before 'mirroring' any docs******* > > > > Many of the key v1.8 docs are very different than their v1.9 > > counterparts: > > > > * Some of the Installing CollectionSpace docs for v1.8 are (at > > least) slightly different than their 1.9 counterparts. > > > > * At least one or two of the core Configuring CollectionSpace docs > > differ substantially from their 1.9 counterparts, to > reflect that the > > app layer configuration changed to a new overlay structure in v1.9. > > > > Before doing any wholesale 'mirroring', it might be good to check a > > chronological list of recently updated documents, and/or > review which > > documents should not be mirrored with both me and Kasper. > > > > Thanks, > > Aron > > > > On Thu, Sep 15, 2011 at 3:08 PM, Jesse Martinez > > <jmartinez@movingimage.us > > > wrote: > >> Heather, > >> I think it's safe to mirror 1.9 onto 1.8 documentation > granted that > >> we be aware of any recent changes to 1.9. Although, I make the > >> assumption that some changes may have occurred on both 1.8 > as well as > >> 1.9 so in that case it's moot. The trouble with links is a big one > >> and if we can straighten it with 1.9 then we'd all be better off > >> since we'll use > >> 1.9 for 1.11 and so on. > >> We just need to make the concerted effort to follow every lin on > >> every page to make sure it's pointing in the right location. > >> I'm not aware of any time out issues for me/us on the east > coast. Was > >> this recently? Did you also see issues with jira or any of > our other > >> services? > >> - Jesse > >> > >> On Thu, Sep 15, 2011 at 3:26 PM, Heather Hart > <hhart@bpoc.org> wrote: > >>> > >>> Hi Joe, > >>> > >>> One documentation issue always leads to several dozen > more. This is > >>> really two separate problems. > >>> > >>> First of all, these pages were not copied over because at > the time > >>> the 1.8 wiki was mirrored from UNRELEASED, we had not yet rescued > >>> these pages from the main wiki where they were buried. If > you look > >>> at the 1.9 wiki space, these pages have been moved over > and appear > >>> in the heirarchy (left sidebar) under the appropriate page. > >>> > >>> Secondly, even though the pages exist where they should > in the 1.9 > >>> wiki, the links are still broken. The links did not travel well > >>> because they are hard-linked (it is linked as a standard > hyperlink: > >>> http://wiki.collectionspace.org/display/collectionspace/How+to > >>> +change > >>> +the+definition+of+a+field+in+the+Services+configuration) > >>> so when we "rescued" these pages, it also broke these links. > >>> Unfortunately, the fluid tools can't tell us (as far as I > know) when > >>> we break hard links. > >>> This is a great reminder to everyone to use the fluid tools when > >>> editing the wiki pages. In this particular case, there is a child > >>> pages macro that would work perfectly. Under normal > circumstances it > >>> is best to link to another cspace wiki page by using the search > >>> function on the edit link screen. > >>> > >>> So, in terms of what we can and should do, the 1.8 wiki > is in pretty > >>> bad shape in general. Jesse, what do you think about re-mirroring > >>> the > >>> 1.9 wiki into 1.8? This is risky if people have been > making changes > >>> to the 1.8 pages. > >>> The 1.9 wiki will include the "rescued" pages, but would > not include > >>> the fruits of our most recent documentation push (much of > which may > >>> apply to 1.8?). > >>> > >>> For now I am going to manually move these pages back into 1.8 and > >>> then use the child macro instead of the hard-coded list > so Joe can > >>> continue his work. > >>> I am having a bit of a time with this, since I keep getting > >>> connection errors and "error retrieving breadcrumbs" problems. Is > >>> anyone else having trouble with the wiki? > >>> > >>> Heather > >>> ________________________________________ > >>> From: talk-bounces@lists.collectionspace.org > >>> [talk-bounces@lists.collectionspace.org] on behalf of Joe Slag > >>> [joe@slagwerks.com] > >>> Sent: Wednesday, September 14, 2011 8:10 AM > >>> To: CollectionSpace Talk List > >>> Subject: [Talk] changed / deprecated links in 1.8 docs > >>> > >>> I was just referring to > >>> > >>> http://wiki.collectionspace.org/display/CSPACE18/How+to+make+a > >>> +field+ > >>> multivalued and noticed that many of the details, under > the heading > >>> "Procedure step checklist", are links to pages that have > been moved > >>> or deprectated. > >>> > >>> For example, > >>> > http://wiki.collectionspace.org/display/collectionspace/How+to+edit > >>> +t > >>> he+definition+of+data+passed+into+and+out+of+a+field+in+the+UI > >>> +schema > >>> +file is linked to in step 2b. The top of that page says in red: > >>> > >>> REMOVE THIS PAGE - IT IS NOT ACCURATE. (FIELDS ARE NOT > EDITED VIA > >>> THE UI SCHEMA FILE) > >>> > >>> Many of the other pages seem to have been moved in a way > that allows > >>> confluence to make a good guess about their location, but still > >>> presents an intermediate 'page moved' page. > >>> > >>> If this was just any old release I don't think it would be that > >>> important, but I thought I'd mention it given 1.8's > positioning as a > >>> thoroughly-QA'd release. Also it might be nice to > identify whatever > >>> process problems led to this problem so that it can be > avoided for > >>> future releases. > >>> > >>> cheers, > >>> Joe > >>> > >>> _______________________________________________ > >>> Talk mailing list > >>> Talk@lists.collectionspace.org > >>> > >>> http://lists.collectionspace.org/mailman/listinfo/ > >>> talk_lists.collecti > >>> onspace.org > >> > >> > >> _______________________________________________ > >> Talk mailing list > >> Talk@lists.collectionspace.org > >> http://lists.collectionspace.org/mailman/listinfo/ > >> talk_lists.collectio > >> nspace.org > >> > >> > > > > _______________________________________________ > > Talk mailing list > > Talk@lists.collectionspace.org > > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectio > > nspace.org > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.c > ollectionspace.org >

On Tue, Sep 20, 2011 at 9:26 AM, Angela Spinazze <atspin@mindspring.com> wrote: > As I was talking with Joe S. last week, he > mentioned that he was trying to figure out where to put the WAC local > schema. Is there a designated place, for example, where the local schema > lives? Is that something that we cover in the documentation? This may be interpreted as either of two questions: 1. Where - within the services layer source code tree - does an implementer add an extension schema, in order to add custom fields? Rick and Jesse both have some recent notes on this process. Those can and should be turned into updated documentation; this may be one of our highest configuration doc priorities, project-wide. Richard has also done some work (in the v1.11/v1.12 space, I believe) toward simplifying the process, so that fewer steps would be involved in making an extension schema in the services. This work may at some point be reflected in the mini-build, as well. 2. Where can implementers contribute extension schemas they've developed, for sharing with other implementers and with the CollectionSpace project team? This appears to have been the question to which Patrick has responded here: On Tue, Sep 20, 2011 at 10:22 AM, Patrick Schmitz <pschmitz@berkeley.edu> wrote: > We have been talking about this, but have yet to put together a good spot > for this. I.e., it is on my plate which means it may wait a little... Aron > >> -----Original Message----- >> From: talk-bounces@lists.collectionspace.org >> [mailto:talk-bounces@lists.collectionspace.org] On Behalf Of >> Angela Spinazze >> Sent: Tuesday, September 20, 2011 9:26 AM >> To: Heather Hart >> Cc: CollectionSpace Talk List >> Subject: Re: [Talk] changed / deprecated links in 1.8 docs >> >> Thanks Heather, Aron, Jesse, and Rick for your work on >> getting this documentation sorted. >> >> One question for you all:  As I was talking with Joe S. last >> week, he mentioned that he was trying to figure out where to >> put the WAC local schema. Is there a designated place, for >> example, where the local schema lives?  Is that something >> that we cover in the documentation? >> >> Thanks, >> >> Angela >> >> On Sep 19, 2011, at 7:58 PM, Heather Hart wrote: >> >> > Hi Aron, >> > >> > Can you take a look at the updated multivalued field 1.8 >> pages and add >> > in the necessary details about the minibuild? >> > >> > >> http://wiki.collectionspace.org/display/CSPACE18/How+to+make+a+field+m >> > ultivalued >> > >> > Also a general review for accuracy as of 1.8 would be >> great. Rick has >> > given it a once over already. >> > >> > Thanks, >> > Heather >> > >> > -----Original Message----- >> > From: Aron Roberts [mailto:aronroberts@gmail.com] >> > Sent: Thursday, September 15, 2011 3:51 PM >> > To: Jesse Martinez; Heather Hart >> > Cc: CollectionSpace Talk List >> > Subject: Re: [Talk] changed / deprecated links in 1.8 docs >> > >> > *******PLEASE READ before 'mirroring' any docs******* >> > >> > Many of the key v1.8 docs are very different than their v1.9 >> > counterparts: >> > >> > * Some of the Installing CollectionSpace docs for v1.8 are (at >> > least) slightly different than their 1.9 counterparts. >> > >> > * At least one or two of the core Configuring CollectionSpace docs >> > differ substantially from their 1.9 counterparts, to >> reflect that the >> > app layer configuration changed to a new overlay structure in v1.9. >> > >> > Before doing any wholesale 'mirroring', it might be good to check a >> > chronological list of recently updated documents, and/or >> review which >> > documents should not be mirrored with both me and Kasper. >> > >> > Thanks, >> > Aron >> > >> > On Thu, Sep 15, 2011 at 3:08 PM, Jesse Martinez >> > <jmartinez@movingimage.us >> > > wrote: >> >> Heather, >> >> I think it's safe to mirror 1.9 onto 1.8 documentation >> granted that >> >> we be aware of any recent changes to 1.9. Although, I make the >> >> assumption that some changes may have occurred on both 1.8 >> as well as >> >> 1.9 so in that case it's moot. The trouble with links is a big one >> >> and if we can straighten it with 1.9 then we'd all be better off >> >> since we'll use >> >> 1.9 for 1.11 and so on. >> >> We just need to make the concerted effort to follow every lin on >> >> every page to make sure it's pointing in the right location. >> >> I'm not aware of any time out issues for me/us on the east >> coast. Was >> >> this recently? Did you also see issues with jira or any of >> our other >> >> services? >> >>  - Jesse >> >> >> >> On Thu, Sep 15, 2011 at 3:26 PM, Heather Hart >> <hhart@bpoc.org> wrote: >> >>> >> >>> Hi Joe, >> >>> >> >>> One documentation issue always leads to several dozen >> more. This is >> >>> really two separate problems. >> >>> >> >>> First of all, these pages were not copied over because at >> the time >> >>> the 1.8 wiki was mirrored from UNRELEASED, we had not yet rescued >> >>> these pages from the main wiki where they were buried. If >> you look >> >>> at the 1.9 wiki space, these pages have been moved over >> and appear >> >>> in the heirarchy (left sidebar) under the appropriate page. >> >>> >> >>> Secondly, even though the pages exist where they should >> in the 1.9 >> >>> wiki, the links are still broken. The links did not travel well >> >>> because they are hard-linked (it is linked as a standard >> hyperlink: >> >>> http://wiki.collectionspace.org/display/collectionspace/How+to >> >>> +change >> >>> +the+definition+of+a+field+in+the+Services+configuration) >> >>> so when we "rescued" these pages, it also broke these links. >> >>> Unfortunately, the fluid tools can't tell us (as far as I >> know) when >> >>> we break hard links. >> >>> This is a great reminder to everyone to use the fluid tools when >> >>> editing the wiki pages. In this particular case, there is a child >> >>> pages macro that would work perfectly. Under normal >> circumstances it >> >>> is best to link to another cspace wiki page by using the search >> >>> function on the edit link screen. >> >>> >> >>> So, in terms of what we can and should do, the 1.8 wiki >> is in pretty >> >>> bad shape in general. Jesse, what do you think about re-mirroring >> >>> the >> >>> 1.9 wiki into 1.8? This is risky if people have been >> making changes >> >>> to the 1.8 pages. >> >>> The 1.9 wiki will include the "rescued" pages, but would >> not include >> >>> the fruits of our most recent documentation push (much of >> which may >> >>> apply to 1.8?). >> >>> >> >>> For now I am going to manually move these pages back into 1.8 and >> >>> then use the child macro instead of the hard-coded list >> so Joe can >> >>> continue his work. >> >>> I am having a bit of a time with this, since I keep getting >> >>> connection errors and "error retrieving breadcrumbs" problems. Is >> >>> anyone else having trouble with the wiki? >> >>> >> >>> Heather >> >>> ________________________________________ >> >>> From: talk-bounces@lists.collectionspace.org >> >>> [talk-bounces@lists.collectionspace.org] on behalf of Joe Slag >> >>> [joe@slagwerks.com] >> >>> Sent: Wednesday, September 14, 2011 8:10 AM >> >>> To: CollectionSpace Talk List >> >>> Subject: [Talk] changed / deprecated links in 1.8 docs >> >>> >> >>> I was just referring to >> >>> >> >>> http://wiki.collectionspace.org/display/CSPACE18/How+to+make+a >> >>> +field+ >> >>> multivalued and noticed that many of the details, under >> the heading >> >>> "Procedure step checklist", are links to pages that have >> been moved >> >>> or deprectated. >> >>> >> >>> For example, >> >>> >> http://wiki.collectionspace.org/display/collectionspace/How+to+edit >> >>> +t >> >>> he+definition+of+data+passed+into+and+out+of+a+field+in+the+UI >> >>> +schema >> >>> +file is linked to in step 2b. The top of that page says in red: >> >>> >> >>>  REMOVE THIS PAGE - IT IS  NOT ACCURATE. (FIELDS ARE NOT >> EDITED VIA >> >>> THE UI SCHEMA FILE) >> >>> >> >>> Many of the other pages seem to have been moved in a way >> that allows >> >>> confluence to make a good guess about their location, but still >> >>> presents an intermediate 'page moved' page. >> >>> >> >>> If this was just any old release I don't think it would be that >> >>> important, but I thought I'd mention it given 1.8's >> positioning as a >> >>> thoroughly-QA'd release. Also it might be nice to >> identify whatever >> >>> process problems led to this problem so that it can be >> avoided for >> >>> future releases. >> >>> >> >>> cheers, >> >>> Joe >> >>> >> >>> _______________________________________________ >> >>> Talk mailing list >> >>> Talk@lists.collectionspace.org >> >>> >> >>> http://lists.collectionspace.org/mailman/listinfo/ >> >>> talk_lists.collecti >> >>> onspace.org >> >> >> >> >> >> _______________________________________________ >> >> Talk mailing list >> >> Talk@lists.collectionspace.org >> >> http://lists.collectionspace.org/mailman/listinfo/ >> >> talk_lists.collectio >> >> nspace.org >> >> >> >> >> > >> > _______________________________________________ >> > Talk mailing list >> > Talk@lists.collectionspace.org >> > >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectio >> > nspace.org >> >> >> _______________________________________________ >> Talk mailing list >> Talk@lists.collectionspace.org >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.c >> ollectionspace.org >> > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >

Angela, Aron, all - Speaking to the first part of Aron's response, here's my (perhaps too-detailed) explanation. In short, there is no special place for a local schema. The local schema goes in the same place as any other extension schema, that being in this location in the services source code tree: services/{recordType, for example, collectionobject or loanin}/3rdparty/nuxeo-platform-{recordtype}-{tenantname}/src/main/resources/schemas/{extension schema name, such as {recordtype_tenantname}.xsd. A real example: services/intake/3rdparty/nuxeo-platform-intake-havrc/src/main/resources/schemas/intake_havrc.xsd. Let me add several notes, at the risk of muddying things up: 1 The fact that the schema is a local, as opposed to domain, schema is determined by naming choices in several places. There is no intrinsic difference. The two important places that come to mind are: a. In services/common/src/main/cspace/config/services/tenants/ <service:xmlContent namespaceURI="http://collectionspace.org/services/media/local/ucjeps" schemaLocation="http://collectionspace.org/services/media/local/ucjeps http://collectionspace.org/services/media/local/media_ucjeps.xsd" />, and b. In the Application layer {tenantname}-tenant.xml file (best to use the mini-build): <services-record-path id="ucjeps">collectionobjects_ucjeps:http://collectionspace.org/services/collectionobject/local/ucjeps,collectionobjects_ucjeps</services-record-path> We often add text to the commented-out section at the head of the schema .xsd file itself, noting that the schema is a local or domain extension: CollectionObject schema (XSD) Entity : CollectionObject Part : Local - UCJEPS (Extends Natural History)... 2. We've seemed to have dropped the "-cs-" bit in the part of the path "nuxeo-platform-{recordtype}-{tenantname}. The common schema is in a folder called "nuxeo-platform-cs-intake", but the extension schema is in a folder called "nuxeo-platform-intake-havrc." This is just a naming convention; either would work, as long as you identified the folder correctly in the build.xml file in the same folder. 3. For extension schemas, we haven't been adding a JAXB, as opposed to Nuxeo, schema. I don't know whether you'd have to if you planned to use a Java Client to hit the services; that's one of the things the JAXB schema handles. Aron has counseled me not to worry about it at this point. Enough for now, Rick On Sep 20, 2011, at 10:33 AM, Aron Roberts wrote: > On Tue, Sep 20, 2011 at 9:26 AM, Angela Spinazze <atspin@mindspring.com> wrote: >> As I was talking with Joe S. last week, he >> mentioned that he was trying to figure out where to put the WAC local >> schema. Is there a designated place, for example, where the local schema >> lives? Is that something that we cover in the documentation? > > This may be interpreted as either of two questions: > > 1. Where - within the services layer source code tree - does an > implementer add an extension schema, in order to add custom fields? > > Rick and Jesse both have some recent notes on this process. Those can > and should be turned into updated documentation; this may be one of > our highest configuration doc priorities, project-wide. > > Richard has also done some work (in the v1.11/v1.12 space, I believe) > toward simplifying the process, so that fewer steps would be involved > in making an extension schema in the services. This work may at some > point be reflected in the mini-build, as well. > > 2. Where can implementers contribute extension schemas they've > developed, for sharing with other implementers and with the > CollectionSpace project team? > > This appears to have been the question to which Patrick has responded here: > > On Tue, Sep 20, 2011 at 10:22 AM, Patrick Schmitz <pschmitz@berkeley.edu> wrote: >> We have been talking about this, but have yet to put together a good spot >> for this. I.e., it is on my plate which means it may wait a little... > > Aron > >> >>> -----Original Message----- >>> From: talk-bounces@lists.collectionspace.org >>> [mailto:talk-bounces@lists.collectionspace.org] On Behalf Of >>> Angela Spinazze >>> Sent: Tuesday, September 20, 2011 9:26 AM >>> To: Heather Hart >>> Cc: CollectionSpace Talk List >>> Subject: Re: [Talk] changed / deprecated links in 1.8 docs >>> >>> Thanks Heather, Aron, Jesse, and Rick for your work on >>> getting this documentation sorted. >>> >>> One question for you all: As I was talking with Joe S. last >>> week, he mentioned that he was trying to figure out where to >>> put the WAC local schema. Is there a designated place, for >>> example, where the local schema lives? Is that something >>> that we cover in the documentation? >>> >>> Thanks, >>> >>> Angela >>> >>> On Sep 19, 2011, at 7:58 PM, Heather Hart wrote: >>> >>>> Hi Aron, >>>> >>>> Can you take a look at the updated multivalued field 1.8 >>> pages and add >>>> in the necessary details about the minibuild? >>>> >>>> >>> http://wiki.collectionspace.org/display/CSPACE18/How+to+make+a+field+m >>>> ultivalued >>>> >>>> Also a general review for accuracy as of 1.8 would be >>> great. Rick has >>>> given it a once over already. >>>> >>>> Thanks, >>>> Heather >>>> >>>> -----Original Message----- >>>> From: Aron Roberts [mailto:aronroberts@gmail.com] >>>> Sent: Thursday, September 15, 2011 3:51 PM >>>> To: Jesse Martinez; Heather Hart >>>> Cc: CollectionSpace Talk List >>>> Subject: Re: [Talk] changed / deprecated links in 1.8 docs >>>> >>>> *******PLEASE READ before 'mirroring' any docs******* >>>> >>>> Many of the key v1.8 docs are very different than their v1.9 >>>> counterparts: >>>> >>>> * Some of the Installing CollectionSpace docs for v1.8 are (at >>>> least) slightly different than their 1.9 counterparts. >>>> >>>> * At least one or two of the core Configuring CollectionSpace docs >>>> differ substantially from their 1.9 counterparts, to >>> reflect that the >>>> app layer configuration changed to a new overlay structure in v1.9. >>>> >>>> Before doing any wholesale 'mirroring', it might be good to check a >>>> chronological list of recently updated documents, and/or >>> review which >>>> documents should not be mirrored with both me and Kasper. >>>> >>>> Thanks, >>>> Aron >>>> >>>> On Thu, Sep 15, 2011 at 3:08 PM, Jesse Martinez >>>> <jmartinez@movingimage.us >>>>> wrote: >>>>> Heather, >>>>> I think it's safe to mirror 1.9 onto 1.8 documentation >>> granted that >>>>> we be aware of any recent changes to 1.9. Although, I make the >>>>> assumption that some changes may have occurred on both 1.8 >>> as well as >>>>> 1.9 so in that case it's moot. The trouble with links is a big one >>>>> and if we can straighten it with 1.9 then we'd all be better off >>>>> since we'll use >>>>> 1.9 for 1.11 and so on. >>>>> We just need to make the concerted effort to follow every lin on >>>>> every page to make sure it's pointing in the right location. >>>>> I'm not aware of any time out issues for me/us on the east >>> coast. Was >>>>> this recently? Did you also see issues with jira or any of >>> our other >>>>> services? >>>>> - Jesse >>>>> >>>>> On Thu, Sep 15, 2011 at 3:26 PM, Heather Hart >>> <hhart@bpoc.org> wrote: >>>>>> >>>>>> Hi Joe, >>>>>> >>>>>> One documentation issue always leads to several dozen >>> more. This is >>>>>> really two separate problems. >>>>>> >>>>>> First of all, these pages were not copied over because at >>> the time >>>>>> the 1.8 wiki was mirrored from UNRELEASED, we had not yet rescued >>>>>> these pages from the main wiki where they were buried. If >>> you look >>>>>> at the 1.9 wiki space, these pages have been moved over >>> and appear >>>>>> in the heirarchy (left sidebar) under the appropriate page. >>>>>> >>>>>> Secondly, even though the pages exist where they should >>> in the 1.9 >>>>>> wiki, the links are still broken. The links did not travel well >>>>>> because they are hard-linked (it is linked as a standard >>> hyperlink: >>>>>> http://wiki.collectionspace.org/display/collectionspace/How+to >>>>>> +change >>>>>> +the+definition+of+a+field+in+the+Services+configuration) >>>>>> so when we "rescued" these pages, it also broke these links. >>>>>> Unfortunately, the fluid tools can't tell us (as far as I >>> know) when >>>>>> we break hard links. >>>>>> This is a great reminder to everyone to use the fluid tools when >>>>>> editing the wiki pages. In this particular case, there is a child >>>>>> pages macro that would work perfectly. Under normal >>> circumstances it >>>>>> is best to link to another cspace wiki page by using the search >>>>>> function on the edit link screen. >>>>>> >>>>>> So, in terms of what we can and should do, the 1.8 wiki >>> is in pretty >>>>>> bad shape in general. Jesse, what do you think about re-mirroring >>>>>> the >>>>>> 1.9 wiki into 1.8? This is risky if people have been >>> making changes >>>>>> to the 1.8 pages. >>>>>> The 1.9 wiki will include the "rescued" pages, but would >>> not include >>>>>> the fruits of our most recent documentation push (much of >>> which may >>>>>> apply to 1.8?). >>>>>> >>>>>> For now I am going to manually move these pages back into 1.8 and >>>>>> then use the child macro instead of the hard-coded list >>> so Joe can >>>>>> continue his work. >>>>>> I am having a bit of a time with this, since I keep getting >>>>>> connection errors and "error retrieving breadcrumbs" problems. Is >>>>>> anyone else having trouble with the wiki? >>>>>> >>>>>> Heather >>>>>> ________________________________________ >>>>>> From: talk-bounces@lists.collectionspace.org >>>>>> [talk-bounces@lists.collectionspace.org] on behalf of Joe Slag >>>>>> [joe@slagwerks.com] >>>>>> Sent: Wednesday, September 14, 2011 8:10 AM >>>>>> To: CollectionSpace Talk List >>>>>> Subject: [Talk] changed / deprecated links in 1.8 docs >>>>>> >>>>>> I was just referring to >>>>>> >>>>>> http://wiki.collectionspace.org/display/CSPACE18/How+to+make+a >>>>>> +field+ >>>>>> multivalued and noticed that many of the details, under >>> the heading >>>>>> "Procedure step checklist", are links to pages that have >>> been moved >>>>>> or deprectated. >>>>>> >>>>>> For example, >>>>>> >>> http://wiki.collectionspace.org/display/collectionspace/How+to+edit >>>>>> +t >>>>>> he+definition+of+data+passed+into+and+out+of+a+field+in+the+UI >>>>>> +schema >>>>>> +file is linked to in step 2b. The top of that page says in red: >>>>>> >>>>>> REMOVE THIS PAGE - IT IS NOT ACCURATE. (FIELDS ARE NOT >>> EDITED VIA >>>>>> THE UI SCHEMA FILE) >>>>>> >>>>>> Many of the other pages seem to have been moved in a way >>> that allows >>>>>> confluence to make a good guess about their location, but still >>>>>> presents an intermediate 'page moved' page. >>>>>> >>>>>> If this was just any old release I don't think it would be that >>>>>> important, but I thought I'd mention it given 1.8's >>> positioning as a >>>>>> thoroughly-QA'd release. Also it might be nice to >>> identify whatever >>>>>> process problems led to this problem so that it can be >>> avoided for >>>>>> future releases. >>>>>> >>>>>> cheers, >>>>>> Joe >>>>>> >>>>>> _______________________________________________ >>>>>> Talk mailing list >>>>>> Talk@lists.collectionspace.org >>>>>> >>>>>> http://lists.collectionspace.org/mailman/listinfo/ >>>>>> talk_lists.collecti >>>>>> onspace.org >>>>> >>>>> >>>>> _______________________________________________ >>>>> Talk mailing list >>>>> Talk@lists.collectionspace.org >>>>> http://lists.collectionspace.org/mailman/listinfo/ >>>>> talk_lists.collectio >>>>> nspace.org >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Talk mailing list >>>> Talk@lists.collectionspace.org >>>> >>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectio >>>> nspace.org >>> >>> >>> _______________________________________________ >>> Talk mailing list >>> Talk@lists.collectionspace.org >>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.c >>> ollectionspace.org >>> >> >> >> _______________________________________________ >> Talk mailing list >> Talk@lists.collectionspace.org >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >> > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Thanks Aron, for the clarification. I was focused more on interpretation #1 than #2 and appreciate your pointing out the differences. Heather, I know that you're working hard on updating and improving our documentation overall. Perhaps once you've had the chance to take a look at where we stand with updates to configuration documentation in light of question #1 below, you could update this thread on the Talk list? Thanks, Angela On Sep 20, 2011, at 12:33 PM, Aron Roberts wrote: > On Tue, Sep 20, 2011 at 9:26 AM, Angela Spinazze <atspin@mindspring.com> wrote: >> As I was talking with Joe S. last week, he >> mentioned that he was trying to figure out where to put the WAC local >> schema. Is there a designated place, for example, where the local schema >> lives? Is that something that we cover in the documentation? > > This may be interpreted as either of two questions: > > 1. Where - within the services layer source code tree - does an > implementer add an extension schema, in order to add custom fields? > > Rick and Jesse both have some recent notes on this process. Those can > and should be turned into updated documentation; this may be one of > our highest configuration doc priorities, project-wide. > > Richard has also done some work (in the v1.11/v1.12 space, I believe) > toward simplifying the process, so that fewer steps would be involved > in making an extension schema in the services. This work may at some > point be reflected in the mini-build, as well. > > 2. Where can implementers contribute extension schemas they've > developed, for sharing with other implementers and with the > CollectionSpace project team? > > This appears to have been the question to which Patrick has responded here: > > On Tue, Sep 20, 2011 at 10:22 AM, Patrick Schmitz <pschmitz@berkeley.edu> wrote: >> We have been talking about this, but have yet to put together a good spot >> for this. I.e., it is on my plate which means it may wait a little... > > Aron > >> >>> -----Original Message----- >>> From: talk-bounces@lists.collectionspace.org >>> [mailto:talk-bounces@lists.collectionspace.org] On Behalf Of >>> Angela Spinazze >>> Sent: Tuesday, September 20, 2011 9:26 AM >>> To: Heather Hart >>> Cc: CollectionSpace Talk List >>> Subject: Re: [Talk] changed / deprecated links in 1.8 docs >>> >>> Thanks Heather, Aron, Jesse, and Rick for your work on >>> getting this documentation sorted. >>> >>> One question for you all: As I was talking with Joe S. last >>> week, he mentioned that he was trying to figure out where to >>> put the WAC local schema. Is there a designated place, for >>> example, where the local schema lives? Is that something >>> that we cover in the documentation? >>> >>> Thanks, >>> >>> Angela >>> >>> On Sep 19, 2011, at 7:58 PM, Heather Hart wrote: >>> >>>> Hi Aron, >>>> >>>> Can you take a look at the updated multivalued field 1.8 >>> pages and add >>>> in the necessary details about the minibuild? >>>> >>>> >>> http://wiki.collectionspace.org/display/CSPACE18/How+to+make+a+field+m >>>> ultivalued >>>> >>>> Also a general review for accuracy as of 1.8 would be >>> great. Rick has >>>> given it a once over already. >>>> >>>> Thanks, >>>> Heather >>>> >>>> -----Original Message----- >>>> From: Aron Roberts [mailto:aronroberts@gmail.com] >>>> Sent: Thursday, September 15, 2011 3:51 PM >>>> To: Jesse Martinez; Heather Hart >>>> Cc: CollectionSpace Talk List >>>> Subject: Re: [Talk] changed / deprecated links in 1.8 docs >>>> >>>> *******PLEASE READ before 'mirroring' any docs******* >>>> >>>> Many of the key v1.8 docs are very different than their v1.9 >>>> counterparts: >>>> >>>> * Some of the Installing CollectionSpace docs for v1.8 are (at >>>> least) slightly different than their 1.9 counterparts. >>>> >>>> * At least one or two of the core Configuring CollectionSpace docs >>>> differ substantially from their 1.9 counterparts, to >>> reflect that the >>>> app layer configuration changed to a new overlay structure in v1.9. >>>> >>>> Before doing any wholesale 'mirroring', it might be good to check a >>>> chronological list of recently updated documents, and/or >>> review which >>>> documents should not be mirrored with both me and Kasper. >>>> >>>> Thanks, >>>> Aron >>>> >>>> On Thu, Sep 15, 2011 at 3:08 PM, Jesse Martinez >>>> <jmartinez@movingimage.us >>>>> wrote: >>>>> Heather, >>>>> I think it's safe to mirror 1.9 onto 1.8 documentation >>> granted that >>>>> we be aware of any recent changes to 1.9. Although, I make the >>>>> assumption that some changes may have occurred on both 1.8 >>> as well as >>>>> 1.9 so in that case it's moot. The trouble with links is a big one >>>>> and if we can straighten it with 1.9 then we'd all be better off >>>>> since we'll use >>>>> 1.9 for 1.11 and so on. >>>>> We just need to make the concerted effort to follow every lin on >>>>> every page to make sure it's pointing in the right location. >>>>> I'm not aware of any time out issues for me/us on the east >>> coast. Was >>>>> this recently? Did you also see issues with jira or any of >>> our other >>>>> services? >>>>> - Jesse >>>>> >>>>> On Thu, Sep 15, 2011 at 3:26 PM, Heather Hart >>> <hhart@bpoc.org> wrote: >>>>>> >>>>>> Hi Joe, >>>>>> >>>>>> One documentation issue always leads to several dozen >>> more. This is >>>>>> really two separate problems. >>>>>> >>>>>> First of all, these pages were not copied over because at >>> the time >>>>>> the 1.8 wiki was mirrored from UNRELEASED, we had not yet rescued >>>>>> these pages from the main wiki where they were buried. If >>> you look >>>>>> at the 1.9 wiki space, these pages have been moved over >>> and appear >>>>>> in the heirarchy (left sidebar) under the appropriate page. >>>>>> >>>>>> Secondly, even though the pages exist where they should >>> in the 1.9 >>>>>> wiki, the links are still broken. The links did not travel well >>>>>> because they are hard-linked (it is linked as a standard >>> hyperlink: >>>>>> http://wiki.collectionspace.org/display/collectionspace/How+to >>>>>> +change >>>>>> +the+definition+of+a+field+in+the+Services+configuration) >>>>>> so when we "rescued" these pages, it also broke these links. >>>>>> Unfortunately, the fluid tools can't tell us (as far as I >>> know) when >>>>>> we break hard links. >>>>>> This is a great reminder to everyone to use the fluid tools when >>>>>> editing the wiki pages. In this particular case, there is a child >>>>>> pages macro that would work perfectly. Under normal >>> circumstances it >>>>>> is best to link to another cspace wiki page by using the search >>>>>> function on the edit link screen. >>>>>> >>>>>> So, in terms of what we can and should do, the 1.8 wiki >>> is in pretty >>>>>> bad shape in general. Jesse, what do you think about re-mirroring >>>>>> the >>>>>> 1.9 wiki into 1.8? This is risky if people have been >>> making changes >>>>>> to the 1.8 pages. >>>>>> The 1.9 wiki will include the "rescued" pages, but would >>> not include >>>>>> the fruits of our most recent documentation push (much of >>> which may >>>>>> apply to 1.8?). >>>>>> >>>>>> For now I am going to manually move these pages back into 1.8 and >>>>>> then use the child macro instead of the hard-coded list >>> so Joe can >>>>>> continue his work. >>>>>> I am having a bit of a time with this, since I keep getting >>>>>> connection errors and "error retrieving breadcrumbs" problems. Is >>>>>> anyone else having trouble with the wiki? >>>>>> >>>>>> Heather >>>>>> ________________________________________ >>>>>> From: talk-bounces@lists.collectionspace.org >>>>>> [talk-bounces@lists.collectionspace.org] on behalf of Joe Slag >>>>>> [joe@slagwerks.com] >>>>>> Sent: Wednesday, September 14, 2011 8:10 AM >>>>>> To: CollectionSpace Talk List >>>>>> Subject: [Talk] changed / deprecated links in 1.8 docs >>>>>> >>>>>> I was just referring to >>>>>> >>>>>> http://wiki.collectionspace.org/display/CSPACE18/How+to+make+a >>>>>> +field+ >>>>>> multivalued and noticed that many of the details, under >>> the heading >>>>>> "Procedure step checklist", are links to pages that have >>> been moved >>>>>> or deprectated. >>>>>> >>>>>> For example, >>>>>> >>> http://wiki.collectionspace.org/display/collectionspace/How+to+edit >>>>>> +t >>>>>> he+definition+of+data+passed+into+and+out+of+a+field+in+the+UI >>>>>> +schema >>>>>> +file is linked to in step 2b. The top of that page says in red: >>>>>> >>>>>> REMOVE THIS PAGE - IT IS NOT ACCURATE. (FIELDS ARE NOT >>> EDITED VIA >>>>>> THE UI SCHEMA FILE) >>>>>> >>>>>> Many of the other pages seem to have been moved in a way >>> that allows >>>>>> confluence to make a good guess about their location, but still >>>>>> presents an intermediate 'page moved' page. >>>>>> >>>>>> If this was just any old release I don't think it would be that >>>>>> important, but I thought I'd mention it given 1.8's >>> positioning as a >>>>>> thoroughly-QA'd release. Also it might be nice to >>> identify whatever >>>>>> process problems led to this problem so that it can be >>> avoided for >>>>>> future releases. >>>>>> >>>>>> cheers, >>>>>> Joe >>>>>> >>>>>> _______________________________________________ >>>>>> Talk mailing list >>>>>> Talk@lists.collectionspace.org >>>>>> >>>>>> http://lists.collectionspace.org/mailman/listinfo/ >>>>>> talk_lists.collecti >>>>>> onspace.org >>>>> >>>>> >>>>> _______________________________________________ >>>>> Talk mailing list >>>>> Talk@lists.collectionspace.org >>>>> http://lists.collectionspace.org/mailman/listinfo/ >>>>> talk_lists.collectio >>>>> nspace.org >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Talk mailing list >>>> Talk@lists.collectionspace.org >>>> >>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectio >>>> nspace.org >>> >>> >>> _______________________________________________ >>> Talk mailing list >>> Talk@lists.collectionspace.org >>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.c >>> ollectionspace.org >>> >> >> >> _______________________________________________ >> Talk mailing list >> Talk@lists.collectionspace.org >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>

Rick, this is helpful, thank you! On Sep 20, 2011, at 12:47 PM, Rick Jaffe wrote: > Angela, Aron, all - > > Speaking to the first part of Aron's response, here's my (perhaps too-detailed) explanation. In short, there is no special place for a local schema. > > The local schema goes in the same place as any other extension schema, that being in this location in the services source code tree: > > services/{recordType, for example, collectionobject or loanin}/3rdparty/nuxeo-platform-{recordtype}-{tenantname}/src/main/resources/schemas/{extension schema name, such as {recordtype_tenantname}.xsd. > > A real example: > services/intake/3rdparty/nuxeo-platform-intake-havrc/src/main/resources/schemas/intake_havrc.xsd. > > Let me add several notes, at the risk of muddying things up: > > 1 The fact that the schema is a local, as opposed to domain, schema is determined by naming choices in several places. There is no intrinsic difference. The two important places that come to mind are: > > a. In services/common/src/main/cspace/config/services/tenants/ > <service:xmlContent namespaceURI="http://collectionspace.org/services/media/local/ucjeps" schemaLocation="http://collectionspace.org/services/media/local/ucjeps http://collectionspace.org/services/media/local/media_ucjeps.xsd" />, and > > b. In the Application layer {tenantname}-tenant.xml file (best to use the mini-build): > <services-record-path id="ucjeps">collectionobjects_ucjeps:http://collectionspace.org/services/collectionobject/local/ucjeps,collectionobjects_ucjeps</services-record-path> > > We often add text to the commented-out section at the head of the schema .xsd file itself, noting that the schema is a local or domain extension: > > CollectionObject schema (XSD) > > Entity : CollectionObject > Part : Local - UCJEPS (Extends Natural History)... > > 2. We've seemed to have dropped the "-cs-" bit in the part of the path "nuxeo-platform-{recordtype}-{tenantname}. The common schema is in a folder called "nuxeo-platform-cs-intake", but the extension schema is in a folder called "nuxeo-platform-intake-havrc." This is just a naming convention; either would work, as long as you identified the folder correctly in the build.xml file in the same folder. > > 3. For extension schemas, we haven't been adding a JAXB, as opposed to Nuxeo, schema. I don't know whether you'd have to if you planned to use a Java Client to hit the services; that's one of the things the JAXB schema handles. Aron has counseled me not to worry about it at this point. > > Enough for now, > Rick > > > On Sep 20, 2011, at 10:33 AM, Aron Roberts wrote: > >> On Tue, Sep 20, 2011 at 9:26 AM, Angela Spinazze <atspin@mindspring.com> wrote: >>> As I was talking with Joe S. last week, he >>> mentioned that he was trying to figure out where to put the WAC local >>> schema. Is there a designated place, for example, where the local schema >>> lives? Is that something that we cover in the documentation? >> >> This may be interpreted as either of two questions: >> >> 1. Where - within the services layer source code tree - does an >> implementer add an extension schema, in order to add custom fields? >> >> Rick and Jesse both have some recent notes on this process. Those can >> and should be turned into updated documentation; this may be one of >> our highest configuration doc priorities, project-wide. >> >> Richard has also done some work (in the v1.11/v1.12 space, I believe) >> toward simplifying the process, so that fewer steps would be involved >> in making an extension schema in the services. This work may at some >> point be reflected in the mini-build, as well. >> >> 2. Where can implementers contribute extension schemas they've >> developed, for sharing with other implementers and with the >> CollectionSpace project team? >> >> This appears to have been the question to which Patrick has responded here: >> >> On Tue, Sep 20, 2011 at 10:22 AM, Patrick Schmitz <pschmitz@berkeley.edu> wrote: >>> We have been talking about this, but have yet to put together a good spot >>> for this. I.e., it is on my plate which means it may wait a little... >> >> Aron >> >>> >>>> -----Original Message----- >>>> From: talk-bounces@lists.collectionspace.org >>>> [mailto:talk-bounces@lists.collectionspace.org] On Behalf Of >>>> Angela Spinazze >>>> Sent: Tuesday, September 20, 2011 9:26 AM >>>> To: Heather Hart >>>> Cc: CollectionSpace Talk List >>>> Subject: Re: [Talk] changed / deprecated links in 1.8 docs >>>> >>>> Thanks Heather, Aron, Jesse, and Rick for your work on >>>> getting this documentation sorted. >>>> >>>> One question for you all: As I was talking with Joe S. last >>>> week, he mentioned that he was trying to figure out where to >>>> put the WAC local schema. Is there a designated place, for >>>> example, where the local schema lives? Is that something >>>> that we cover in the documentation? >>>> >>>> Thanks, >>>> >>>> Angela >>>> >>>> On Sep 19, 2011, at 7:58 PM, Heather Hart wrote: >>>> >>>>> Hi Aron, >>>>> >>>>> Can you take a look at the updated multivalued field 1.8 >>>> pages and add >>>>> in the necessary details about the minibuild? >>>>> >>>>> >>>> http://wiki.collectionspace.org/display/CSPACE18/How+to+make+a+field+m >>>>> ultivalued >>>>> >>>>> Also a general review for accuracy as of 1.8 would be >>>> great. Rick has >>>>> given it a once over already. >>>>> >>>>> Thanks, >>>>> Heather >>>>> >>>>> -----Original Message----- >>>>> From: Aron Roberts [mailto:aronroberts@gmail.com] >>>>> Sent: Thursday, September 15, 2011 3:51 PM >>>>> To: Jesse Martinez; Heather Hart >>>>> Cc: CollectionSpace Talk List >>>>> Subject: Re: [Talk] changed / deprecated links in 1.8 docs >>>>> >>>>> *******PLEASE READ before 'mirroring' any docs******* >>>>> >>>>> Many of the key v1.8 docs are very different than their v1.9 >>>>> counterparts: >>>>> >>>>> * Some of the Installing CollectionSpace docs for v1.8 are (at >>>>> least) slightly different than their 1.9 counterparts. >>>>> >>>>> * At least one or two of the core Configuring CollectionSpace docs >>>>> differ substantially from their 1.9 counterparts, to >>>> reflect that the >>>>> app layer configuration changed to a new overlay structure in v1.9. >>>>> >>>>> Before doing any wholesale 'mirroring', it might be good to check a >>>>> chronological list of recently updated documents, and/or >>>> review which >>>>> documents should not be mirrored with both me and Kasper. >>>>> >>>>> Thanks, >>>>> Aron >>>>> >>>>> On Thu, Sep 15, 2011 at 3:08 PM, Jesse Martinez >>>>> <jmartinez@movingimage.us >>>>>> wrote: >>>>>> Heather, >>>>>> I think it's safe to mirror 1.9 onto 1.8 documentation >>>> granted that >>>>>> we be aware of any recent changes to 1.9. Although, I make the >>>>>> assumption that some changes may have occurred on both 1.8 >>>> as well as >>>>>> 1.9 so in that case it's moot. The trouble with links is a big one >>>>>> and if we can straighten it with 1.9 then we'd all be better off >>>>>> since we'll use >>>>>> 1.9 for 1.11 and so on. >>>>>> We just need to make the concerted effort to follow every lin on >>>>>> every page to make sure it's pointing in the right location. >>>>>> I'm not aware of any time out issues for me/us on the east >>>> coast. Was >>>>>> this recently? Did you also see issues with jira or any of >>>> our other >>>>>> services? >>>>>> - Jesse >>>>>> >>>>>> On Thu, Sep 15, 2011 at 3:26 PM, Heather Hart >>>> <hhart@bpoc.org> wrote: >>>>>>> >>>>>>> Hi Joe, >>>>>>> >>>>>>> One documentation issue always leads to several dozen >>>> more. This is >>>>>>> really two separate problems. >>>>>>> >>>>>>> First of all, these pages were not copied over because at >>>> the time >>>>>>> the 1.8 wiki was mirrored from UNRELEASED, we had not yet rescued >>>>>>> these pages from the main wiki where they were buried. If >>>> you look >>>>>>> at the 1.9 wiki space, these pages have been moved over >>>> and appear >>>>>>> in the heirarchy (left sidebar) under the appropriate page. >>>>>>> >>>>>>> Secondly, even though the pages exist where they should >>>> in the 1.9 >>>>>>> wiki, the links are still broken. The links did not travel well >>>>>>> because they are hard-linked (it is linked as a standard >>>> hyperlink: >>>>>>> http://wiki.collectionspace.org/display/collectionspace/How+to >>>>>>> +change >>>>>>> +the+definition+of+a+field+in+the+Services+configuration) >>>>>>> so when we "rescued" these pages, it also broke these links. >>>>>>> Unfortunately, the fluid tools can't tell us (as far as I >>>> know) when >>>>>>> we break hard links. >>>>>>> This is a great reminder to everyone to use the fluid tools when >>>>>>> editing the wiki pages. In this particular case, there is a child >>>>>>> pages macro that would work perfectly. Under normal >>>> circumstances it >>>>>>> is best to link to another cspace wiki page by using the search >>>>>>> function on the edit link screen. >>>>>>> >>>>>>> So, in terms of what we can and should do, the 1.8 wiki >>>> is in pretty >>>>>>> bad shape in general. Jesse, what do you think about re-mirroring >>>>>>> the >>>>>>> 1.9 wiki into 1.8? This is risky if people have been >>>> making changes >>>>>>> to the 1.8 pages. >>>>>>> The 1.9 wiki will include the "rescued" pages, but would >>>> not include >>>>>>> the fruits of our most recent documentation push (much of >>>> which may >>>>>>> apply to 1.8?). >>>>>>> >>>>>>> For now I am going to manually move these pages back into 1.8 and >>>>>>> then use the child macro instead of the hard-coded list >>>> so Joe can >>>>>>> continue his work. >>>>>>> I am having a bit of a time with this, since I keep getting >>>>>>> connection errors and "error retrieving breadcrumbs" problems. Is >>>>>>> anyone else having trouble with the wiki? >>>>>>> >>>>>>> Heather >>>>>>> ________________________________________ >>>>>>> From: talk-bounces@lists.collectionspace.org >>>>>>> [talk-bounces@lists.collectionspace.org] on behalf of Joe Slag >>>>>>> [joe@slagwerks.com] >>>>>>> Sent: Wednesday, September 14, 2011 8:10 AM >>>>>>> To: CollectionSpace Talk List >>>>>>> Subject: [Talk] changed / deprecated links in 1.8 docs >>>>>>> >>>>>>> I was just referring to >>>>>>> >>>>>>> http://wiki.collectionspace.org/display/CSPACE18/How+to+make+a >>>>>>> +field+ >>>>>>> multivalued and noticed that many of the details, under >>>> the heading >>>>>>> "Procedure step checklist", are links to pages that have >>>> been moved >>>>>>> or deprectated. >>>>>>> >>>>>>> For example, >>>>>>> >>>> http://wiki.collectionspace.org/display/collectionspace/How+to+edit >>>>>>> +t >>>>>>> he+definition+of+data+passed+into+and+out+of+a+field+in+the+UI >>>>>>> +schema >>>>>>> +file is linked to in step 2b. The top of that page says in red: >>>>>>> >>>>>>> REMOVE THIS PAGE - IT IS NOT ACCURATE. (FIELDS ARE NOT >>>> EDITED VIA >>>>>>> THE UI SCHEMA FILE) >>>>>>> >>>>>>> Many of the other pages seem to have been moved in a way >>>> that allows >>>>>>> confluence to make a good guess about their location, but still >>>>>>> presents an intermediate 'page moved' page. >>>>>>> >>>>>>> If this was just any old release I don't think it would be that >>>>>>> important, but I thought I'd mention it given 1.8's >>>> positioning as a >>>>>>> thoroughly-QA'd release. Also it might be nice to >>>> identify whatever >>>>>>> process problems led to this problem so that it can be >>>> avoided for >>>>>>> future releases. >>>>>>> >>>>>>> cheers, >>>>>>> Joe >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Talk mailing list >>>>>>> Talk@lists.collectionspace.org >>>>>>> >>>>>>> http://lists.collectionspace.org/mailman/listinfo/ >>>>>>> talk_lists.collecti >>>>>>> onspace.org >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Talk mailing list >>>>>> Talk@lists.collectionspace.org >>>>>> http://lists.collectionspace.org/mailman/listinfo/ >>>>>> talk_lists.collectio >>>>>> nspace.org >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Talk mailing list >>>>> Talk@lists.collectionspace.org >>>>> >>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectio >>>>> nspace.org >>>> >>>> >>>> _______________________________________________ >>>> Talk mailing list >>>> Talk@lists.collectionspace.org >>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.c >>>> ollectionspace.org >>>> >>> >>> >>> _______________________________________________ >>> Talk mailing list >>> Talk@lists.collectionspace.org >>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>> >> >> _______________________________________________ >> Talk mailing list >> Talk@lists.collectionspace.org >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

I left off one important detail in my rush to press. (This is a fast-moving thread!) In 1a., below, the tag in question comes from the tenant-bindings.delta.xml file> The line should read: ... a. In services/common/src/main/cspace/config/services/tenants/tenant-bindings.delta.xml : <service:xmlContent namespaceURI="http://collectionspace.org/services/media/local/ucjeps" schemaLocation="http://collectionspace.org/services/media/local/ucjeps http://collectionspace.org/services/media/local/media_ucjeps.xsd" />, and ... - Rick --- Angela, Aron, all - Speaking to the first part of Aron's response, here's my (perhaps too-detailed) explanation. In short, there is no special place for a local schema. The local schema goes in the same place as any other extension schema, that being in this location in the services source code tree: services/{recordType, for example, collectionobject or loanin}/3rdparty/nuxeo-platform-{recordtype}-{tenantname}/src/main/resources/schemas/{extension schema name, such as {recordtype_tenantname}.xsd. A real example: services/intake/3rdparty/nuxeo-platform-intake-havrc/src/main/resources/schemas/intake_havrc.xsd. Let me add several notes, at the risk of muddying things up: 1 The fact that the schema is a local, as opposed to domain, schema is determined by naming choices in several places. There is no intrinsic difference. The two important places that come to mind are: a. In services/common/src/main/cspace/config/services/tenants/ <service:xmlContent namespaceURI="http://collectionspace.org/services/media/local/ucjeps" schemaLocation="http://collectionspace.org/services/media/local/ucjeps http://collectionspace.org/services/media/local/media_ucjeps.xsd" />, and b. In the Application layer {tenantname}-tenant.xml file (best to use the mini-build): <services-record-path id="ucjeps">collectionobjects_ucjeps:http://collectionspace.org/services/collectionobject/local/ucjeps,collectionobjects_ucjeps</services-record-path> We often add text to the commented-out section at the head of the schema .xsd file itself, noting that the schema is a local or domain extension: CollectionObject schema (XSD) Entity : CollectionObject Part : Local - UCJEPS (Extends Natural History)... 2. We've seemed to have dropped the "-cs-" bit in the part of the path "nuxeo-platform-{recordtype}-{tenantname}. The common schema is in a folder called "nuxeo-platform-cs-intake", but the extension schema is in a folder called "nuxeo-platform-intake-havrc." This is just a naming convention; either would work, as long as you identified the folder correctly in the build.xml file in the same folder. 3. For extension schemas, we haven't been adding a JAXB, as opposed to Nuxeo, schema. I don't know whether you'd have to if you planned to use a Java Client to hit the services; that's one of the things the JAXB schema handles. Aron has counseled me not to worry about it at this point. Enough for now, Rick On Sep 20, 2011, at 10:33 AM, Aron Roberts wrote: > On Tue, Sep 20, 2011 at 9:26 AM, Angela Spinazze <atspin@mindspring.com> wrote: >> As I was talking with Joe S. last week, he >> mentioned that he was trying to figure out where to put the WAC local >> schema. Is there a designated place, for example, where the local schema >> lives? Is that something that we cover in the documentation? > > This may be interpreted as either of two questions: > > 1. Where - within the services layer source code tree - does an > implementer add an extension schema, in order to add custom fields? > > Rick and Jesse both have some recent notes on this process. Those can > and should be turned into updated documentation; this may be one of > our highest configuration doc priorities, project-wide. > > Richard has also done some work (in the v1.11/v1.12 space, I believe) > toward simplifying the process, so that fewer steps would be involved > in making an extension schema in the services. This work may at some > point be reflected in the mini-build, as well. > > 2. Where can implementers contribute extension schemas they've > developed, for sharing with other implementers and with the > CollectionSpace project team? > > This appears to have been the question to which Patrick has responded here: > > On Tue, Sep 20, 2011 at 10:22 AM, Patrick Schmitz <pschmitz@berkeley.edu> wrote: >> We have been talking about this, but have yet to put together a good spot >> for this. I.e., it is on my plate which means it may wait a little... > > Aron > >> >>> -----Original Message----- >>> From: talk-bounces@lists.collectionspace.org >>> [mailto:talk-bounces@lists.collectionspace.org] On Behalf Of >>> Angela Spinazze >>> Sent: Tuesday, September 20, 2011 9:26 AM >>> To: Heather Hart >>> Cc: CollectionSpace Talk List >>> Subject: Re: [Talk] changed / deprecated links in 1.8 docs >>> >>> Thanks Heather, Aron, Jesse, and Rick for your work on >>> getting this documentation sorted. >>> >>> One question for you all: As I was talking with Joe S. last >>> week, he mentioned that he was trying to figure out where to >>> put the WAC local schema. Is there a designated place, for >>> example, where the local schema lives? Is that something >>> that we cover in the documentation? >>> >>> Thanks, >>> >>> Angela >>> >>> On Sep 19, 2011, at 7:58 PM, Heather Hart wrote: >>> >>>> Hi Aron, >>>> >>>> Can you take a look at the updated multivalued field 1.8 >>> pages and add >>>> in the necessary details about the minibuild? >>>> >>>> >>> http://wiki.collectionspace.org/display/CSPACE18/How+to+make+a+field+m >>>> ultivalued >>>> >>>> Also a general review for accuracy as of 1.8 would be >>> great. Rick has >>>> given it a once over already. >>>> >>>> Thanks, >>>> Heather >>>> >>>> -----Original Message----- >>>> From: Aron Roberts [mailto:aronroberts@gmail.com] >>>> Sent: Thursday, September 15, 2011 3:51 PM >>>> To: Jesse Martinez; Heather Hart >>>> Cc: CollectionSpace Talk List >>>> Subject: Re: [Talk] changed / deprecated links in 1.8 docs >>>> >>>> *******PLEASE READ before 'mirroring' any docs******* >>>> >>>> Many of the key v1.8 docs are very different than their v1.9 >>>> counterparts: >>>> >>>> * Some of the Installing CollectionSpace docs for v1.8 are (at >>>> least) slightly different than their 1.9 counterparts. >>>> >>>> * At least one or two of the core Configuring CollectionSpace docs >>>> differ substantially from their 1.9 counterparts, to >>> reflect that the >>>> app layer configuration changed to a new overlay structure in v1.9. >>>> >>>> Before doing any wholesale 'mirroring', it might be good to check a >>>> chronological list of recently updated documents, and/or >>> review which >>>> documents should not be mirrored with both me and Kasper. >>>> >>>> Thanks, >>>> Aron >>>> >>>> On Thu, Sep 15, 2011 at 3:08 PM, Jesse Martinez >>>> <jmartinez@movingimage.us >>>>> wrote: >>>>> Heather, >>>>> I think it's safe to mirror 1.9 onto 1.8 documentation >>> granted that >>>>> we be aware of any recent changes to 1.9. Although, I make the >>>>> assumption that some changes may have occurred on both 1.8 >>> as well as >>>>> 1.9 so in that case it's moot. The trouble with links is a big one >>>>> and if we can straighten it with 1.9 then we'd all be better off >>>>> since we'll use >>>>> 1.9 for 1.11 and so on. >>>>> We just need to make the concerted effort to follow every lin on >>>>> every page to make sure it's pointing in the right location. >>>>> I'm not aware of any time out issues for me/us on the east >>> coast. Was >>>>> this recently? Did you also see issues with jira or any of >>> our other >>>>> services? >>>>> - Jesse >>>>> >>>>> On Thu, Sep 15, 2011 at 3:26 PM, Heather Hart >>> <hhart@bpoc.org> wrote: >>>>>> >>>>>> Hi Joe, >>>>>> >>>>>> One documentation issue always leads to several dozen >>> more. This is >>>>>> really two separate problems. >>>>>> >>>>>> First of all, these pages were not copied over because at >>> the time >>>>>> the 1.8 wiki was mirrored from UNRELEASED, we had not yet rescued >>>>>> these pages from the main wiki where they were buried. If >>> you look >>>>>> at the 1.9 wiki space, these pages have been moved over >>> and appear >>>>>> in the heirarchy (left sidebar) under the appropriate page. >>>>>> >>>>>> Secondly, even though the pages exist where they should >>> in the 1.9 >>>>>> wiki, the links are still broken. The links did not travel well >>>>>> because they are hard-linked (it is linked as a standard >>> hyperlink: >>>>>> http://wiki.collectionspace.org/display/collectionspace/How+to >>>>>> +change >>>>>> +the+definition+of+a+field+in+the+Services+configuration) >>>>>> so when we "rescued" these pages, it also broke these links. >>>>>> Unfortunately, the fluid tools can't tell us (as far as I >>> know) when >>>>>> we break hard links. >>>>>> This is a great reminder to everyone to use the fluid tools when >>>>>> editing the wiki pages. In this particular case, there is a child >>>>>> pages macro that would work perfectly. Under normal >>> circumstances it >>>>>> is best to link to another cspace wiki page by using the search >>>>>> function on the edit link screen. >>>>>> >>>>>> So, in terms of what we can and should do, the 1.8 wiki >>> is in pretty >>>>>> bad shape in general. Jesse, what do you think about re-mirroring >>>>>> the >>>>>> 1.9 wiki into 1.8? This is risky if people have been >>> making changes >>>>>> to the 1.8 pages. >>>>>> The 1.9 wiki will include the "rescued" pages, but would >>> not include >>>>>> the fruits of our most recent documentation push (much of >>> which may >>>>>> apply to 1.8?). >>>>>> >>>>>> For now I am going to manually move these pages back into 1.8 and >>>>>> then use the child macro instead of the hard-coded list >>> so Joe can >>>>>> continue his work. >>>>>> I am having a bit of a time with this, since I keep getting >>>>>> connection errors and "error retrieving breadcrumbs" problems. Is >>>>>> anyone else having trouble with the wiki? >>>>>> >>>>>> Heather >>>>>> ________________________________________ >>>>>> From: talk-bounces@lists.collectionspace.org >>>>>> [talk-bounces@lists.collectionspace.org] on behalf of Joe Slag >>>>>> [joe@slagwerks.com] >>>>>> Sent: Wednesday, September 14, 2011 8:10 AM >>>>>> To: CollectionSpace Talk List >>>>>> Subject: [Talk] changed / deprecated links in 1.8 docs >>>>>> >>>>>> I was just referring to >>>>>> >>>>>> http://wiki.collectionspace.org/display/CSPACE18/How+to+make+a >>>>>> +field+ >>>>>> multivalued and noticed that many of the details, under >>> the heading >>>>>> "Procedure step checklist", are links to pages that have >>> been moved >>>>>> or deprectated. >>>>>> >>>>>> For example, >>>>>> >>> http://wiki.collectionspace.org/display/collectionspace/How+to+edit >>>>>> +t >>>>>> he+definition+of+data+passed+into+and+out+of+a+field+in+the+UI >>>>>> +schema >>>>>> +file is linked to in step 2b. The top of that page says in red: >>>>>> >>>>>> REMOVE THIS PAGE - IT IS NOT ACCURATE. (FIELDS ARE NOT >>> EDITED VIA >>>>>> THE UI SCHEMA FILE) >>>>>> >>>>>> Many of the other pages seem to have been moved in a way >>> that allows >>>>>> confluence to make a good guess about their location, but still >>>>>> presents an intermediate 'page moved' page. >>>>>> >>>>>> If this was just any old release I don't think it would be that >>>>>> important, but I thought I'd mention it given 1.8's >>> positioning as a >>>>>> thoroughly-QA'd release. Also it might be nice to >>> identify whatever >>>>>> process problems led to this problem so that it can be >>> avoided for >>>>>> future releases. >>>>>> >>>>>> cheers, >>>>>> Joe >>>>>> >>>>>> _______________________________________________ >>>>>> Talk mailing list >>>>>> Talk@lists.collectionspace.org >>>>>> >>>>>> http://lists.collectionspace.org/mailman/listinfo/ >>>>>> talk_lists.collecti >>>>>> onspace.org >>>>> >>>>> >>>>> _______________________________________________ >>>>> Talk mailing list >>>>> Talk@lists.collectionspace.org >>>>> http://lists.collectionspace.org/mailman/listinfo/ >>>>> talk_lists.collectio >>>>> nspace.org >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Talk mailing list >>>> Talk@lists.collectionspace.org >>>> >>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectio >>>> nspace.org >>> >>> >>> _______________________________________________ >>> Talk mailing list >>> Talk@lists.collectionspace.org >>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.c >>> ollectionspace.org >>> >> >> >> _______________________________________________ >> Talk mailing list >> Talk@lists.collectionspace.org >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >> > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org _______________________________________________ Talk mailing list Talk@lists.collectionspace.org http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

All- In rushing to respond, I cc'ed a colleague here at UC Berkeley named Angelica Espinoza... I wish I could blame autocomplete. Anyway, please remove than name and address from any cc's. Thanks! Rick On Sep 20, 2011, at 10:56 AM, Rick Jaffe wrote: > I left off one important detail in my rush to press. (This is a fast-moving thread!) In 1a., below, the tag in question comes from the tenant-bindings.delta.xml file> > The line should read: > > ... > a. In services/common/src/main/cspace/config/services/tenants/tenant-bindings.delta.xml : > <service:xmlContent namespaceURI="http://collectionspace.org/services/media/local/ucjeps" schemaLocation="http://collectionspace.org/services/media/local/ucjeps http://collectionspace.org/services/media/local/media_ucjeps.xsd" />, and ... > > - Rick > > --- > > Angela, Aron, all - > > Speaking to the first part of Aron's response, here's my (perhaps too-detailed) explanation. In short, there is no special place for a local schema. > > The local schema goes in the same place as any other extension schema, that being in this location in the services source code tree: > > services/{recordType, for example, collectionobject or loanin}/3rdparty/nuxeo-platform-{recordtype}-{tenantname}/src/main/resources/schemas/{extension schema name, such as {recordtype_tenantname}.xsd. > > A real example: > services/intake/3rdparty/nuxeo-platform-intake-havrc/src/main/resources/schemas/intake_havrc.xsd. > > Let me add several notes, at the risk of muddying things up: > > 1 The fact that the schema is a local, as opposed to domain, schema is determined by naming choices in several places. There is no intrinsic difference. The two important places that come to mind are: > > a. In services/common/src/main/cspace/config/services/tenants/ > <service:xmlContent namespaceURI="http://collectionspace.org/services/media/local/ucjeps" schemaLocation="http://collectionspace.org/services/media/local/ucjeps http://collectionspace.org/services/media/local/media_ucjeps.xsd" />, and > > b. In the Application layer {tenantname}-tenant.xml file (best to use the mini-build): > <services-record-path id="ucjeps">collectionobjects_ucjeps:http://collectionspace.org/services/collectionobject/local/ucjeps,collectionobjects_ucjeps</services-record-path> > > We often add text to the commented-out section at the head of the schema .xsd file itself, noting that the schema is a local or domain extension: > > CollectionObject schema (XSD) > > Entity : CollectionObject > Part : Local - UCJEPS (Extends Natural History)... > > 2. We've seemed to have dropped the "-cs-" bit in the part of the path "nuxeo-platform-{recordtype}-{tenantname}. The common schema is in a folder called "nuxeo-platform-cs-intake", but the extension schema is in a folder called "nuxeo-platform-intake-havrc." This is just a naming convention; either would work, as long as you identified the folder correctly in the build.xml file in the same folder. > > 3. For extension schemas, we haven't been adding a JAXB, as opposed to Nuxeo, schema. I don't know whether you'd have to if you planned to use a Java Client to hit the services; that's one of the things the JAXB schema handles. Aron has counseled me not to worry about it at this point. > > Enough for now, > Rick > > > On Sep 20, 2011, at 10:33 AM, Aron Roberts wrote: > >> On Tue, Sep 20, 2011 at 9:26 AM, Angela Spinazze <atspin@mindspring.com> wrote: >>> As I was talking with Joe S. last week, he >>> mentioned that he was trying to figure out where to put the WAC local >>> schema. Is there a designated place, for example, where the local schema >>> lives? Is that something that we cover in the documentation? >> >> This may be interpreted as either of two questions: >> >> 1. Where - within the services layer source code tree - does an >> implementer add an extension schema, in order to add custom fields? >> >> Rick and Jesse both have some recent notes on this process. Those can >> and should be turned into updated documentation; this may be one of >> our highest configuration doc priorities, project-wide. >> >> Richard has also done some work (in the v1.11/v1.12 space, I believe) >> toward simplifying the process, so that fewer steps would be involved >> in making an extension schema in the services. This work may at some >> point be reflected in the mini-build, as well. >> >> 2. Where can implementers contribute extension schemas they've >> developed, for sharing with other implementers and with the >> CollectionSpace project team? >> >> This appears to have been the question to which Patrick has responded here: >> >> On Tue, Sep 20, 2011 at 10:22 AM, Patrick Schmitz <pschmitz@berkeley.edu> wrote: >>> We have been talking about this, but have yet to put together a good spot >>> for this. I.e., it is on my plate which means it may wait a little... >> >> Aron >> >>> >>>> -----Original Message----- >>>> From: talk-bounces@lists.collectionspace.org >>>> [mailto:talk-bounces@lists.collectionspace.org] On Behalf Of >>>> Angela Spinazze >>>> Sent: Tuesday, September 20, 2011 9:26 AM >>>> To: Heather Hart >>>> Cc: CollectionSpace Talk List >>>> Subject: Re: [Talk] changed / deprecated links in 1.8 docs >>>> >>>> Thanks Heather, Aron, Jesse, and Rick for your work on >>>> getting this documentation sorted. >>>> >>>> One question for you all: As I was talking with Joe S. last >>>> week, he mentioned that he was trying to figure out where to >>>> put the WAC local schema. Is there a designated place, for >>>> example, where the local schema lives? Is that something >>>> that we cover in the documentation? >>>> >>>> Thanks, >>>> >>>> Angela >>>> >>>> On Sep 19, 2011, at 7:58 PM, Heather Hart wrote: >>>> >>>>> Hi Aron, >>>>> >>>>> Can you take a look at the updated multivalued field 1.8 >>>> pages and add >>>>> in the necessary details about the minibuild? >>>>> >>>>> >>>> http://wiki.collectionspace.org/display/CSPACE18/How+to+make+a+field+m >>>>> ultivalued >>>>> >>>>> Also a general review for accuracy as of 1.8 would be >>>> great. Rick has >>>>> given it a once over already. >>>>> >>>>> Thanks, >>>>> Heather >>>>> >>>>> -----Original Message----- >>>>> From: Aron Roberts [mailto:aronroberts@gmail.com] >>>>> Sent: Thursday, September 15, 2011 3:51 PM >>>>> To: Jesse Martinez; Heather Hart >>>>> Cc: CollectionSpace Talk List >>>>> Subject: Re: [Talk] changed / deprecated links in 1.8 docs >>>>> >>>>> *******PLEASE READ before 'mirroring' any docs******* >>>>> >>>>> Many of the key v1.8 docs are very different than their v1.9 >>>>> counterparts: >>>>> >>>>> * Some of the Installing CollectionSpace docs for v1.8 are (at >>>>> least) slightly different than their 1.9 counterparts. >>>>> >>>>> * At least one or two of the core Configuring CollectionSpace docs >>>>> differ substantially from their 1.9 counterparts, to >>>> reflect that the >>>>> app layer configuration changed to a new overlay structure in v1.9. >>>>> >>>>> Before doing any wholesale 'mirroring', it might be good to check a >>>>> chronological list of recently updated documents, and/or >>>> review which >>>>> documents should not be mirrored with both me and Kasper. >>>>> >>>>> Thanks, >>>>> Aron >>>>> >>>>> On Thu, Sep 15, 2011 at 3:08 PM, Jesse Martinez >>>>> <jmartinez@movingimage.us >>>>>> wrote: >>>>>> Heather, >>>>>> I think it's safe to mirror 1.9 onto 1.8 documentation >>>> granted that >>>>>> we be aware of any recent changes to 1.9. Although, I make the >>>>>> assumption that some changes may have occurred on both 1.8 >>>> as well as >>>>>> 1.9 so in that case it's moot. The trouble with links is a big one >>>>>> and if we can straighten it with 1.9 then we'd all be better off >>>>>> since we'll use >>>>>> 1.9 for 1.11 and so on. >>>>>> We just need to make the concerted effort to follow every lin on >>>>>> every page to make sure it's pointing in the right location. >>>>>> I'm not aware of any time out issues for me/us on the east >>>> coast. Was >>>>>> this recently? Did you also see issues with jira or any of >>>> our other >>>>>> services? >>>>>> - Jesse >>>>>> >>>>>> On Thu, Sep 15, 2011 at 3:26 PM, Heather Hart >>>> <hhart@bpoc.org> wrote: >>>>>>> >>>>>>> Hi Joe, >>>>>>> >>>>>>> One documentation issue always leads to several dozen >>>> more. This is >>>>>>> really two separate problems. >>>>>>> >>>>>>> First of all, these pages were not copied over because at >>>> the time >>>>>>> the 1.8 wiki was mirrored from UNRELEASED, we had not yet rescued >>>>>>> these pages from the main wiki where they were buried. If >>>> you look >>>>>>> at the 1.9 wiki space, these pages have been moved over >>>> and appear >>>>>>> in the heirarchy (left sidebar) under the appropriate page. >>>>>>> >>>>>>> Secondly, even though the pages exist where they should >>>> in the 1.9 >>>>>>> wiki, the links are still broken. The links did not travel well >>>>>>> because they are hard-linked (it is linked as a standard >>>> hyperlink: >>>>>>> http://wiki.collectionspace.org/display/collectionspace/How+to >>>>>>> +change >>>>>>> +the+definition+of+a+field+in+the+Services+configuration) >>>>>>> so when we "rescued" these pages, it also broke these links. >>>>>>> Unfortunately, the fluid tools can't tell us (as far as I >>>> know) when >>>>>>> we break hard links. >>>>>>> This is a great reminder to everyone to use the fluid tools when >>>>>>> editing the wiki pages. In this particular case, there is a child >>>>>>> pages macro that would work perfectly. Under normal >>>> circumstances it >>>>>>> is best to link to another cspace wiki page by using the search >>>>>>> function on the edit link screen. >>>>>>> >>>>>>> So, in terms of what we can and should do, the 1.8 wiki >>>> is in pretty >>>>>>> bad shape in general. Jesse, what do you think about re-mirroring >>>>>>> the >>>>>>> 1.9 wiki into 1.8? This is risky if people have been >>>> making changes >>>>>>> to the 1.8 pages. >>>>>>> The 1.9 wiki will include the "rescued" pages, but would >>>> not include >>>>>>> the fruits of our most recent documentation push (much of >>>> which may >>>>>>> apply to 1.8?). >>>>>>> >>>>>>> For now I am going to manually move these pages back into 1.8 and >>>>>>> then use the child macro instead of the hard-coded list >>>> so Joe can >>>>>>> continue his work. >>>>>>> I am having a bit of a time with this, since I keep getting >>>>>>> connection errors and "error retrieving breadcrumbs" problems. Is >>>>>>> anyone else having trouble with the wiki? >>>>>>> >>>>>>> Heather >>>>>>> ________________________________________ >>>>>>> From: talk-bounces@lists.collectionspace.org >>>>>>> [talk-bounces@lists.collectionspace.org] on behalf of Joe Slag >>>>>>> [joe@slagwerks.com] >>>>>>> Sent: Wednesday, September 14, 2011 8:10 AM >>>>>>> To: CollectionSpace Talk List >>>>>>> Subject: [Talk] changed / deprecated links in 1.8 docs >>>>>>> >>>>>>> I was just referring to >>>>>>> >>>>>>> http://wiki.collectionspace.org/display/CSPACE18/How+to+make+a >>>>>>> +field+ >>>>>>> multivalued and noticed that many of the details, under >>>> the heading >>>>>>> "Procedure step checklist", are links to pages that have >>>> been moved >>>>>>> or deprectated. >>>>>>> >>>>>>> For example, >>>>>>> >>>> http://wiki.collectionspace.org/display/collectionspace/How+to+edit >>>>>>> +t >>>>>>> he+definition+of+data+passed+into+and+out+of+a+field+in+the+UI >>>>>>> +schema >>>>>>> +file is linked to in step 2b. The top of that page says in red: >>>>>>> >>>>>>> REMOVE THIS PAGE - IT IS NOT ACCURATE. (FIELDS ARE NOT >>>> EDITED VIA >>>>>>> THE UI SCHEMA FILE) >>>>>>> >>>>>>> Many of the other pages seem to have been moved in a way >>>> that allows >>>>>>> confluence to make a good guess about their location, but still >>>>>>> presents an intermediate 'page moved' page. >>>>>>> >>>>>>> If this was just any old release I don't think it would be that >>>>>>> important, but I thought I'd mention it given 1.8's >>>> positioning as a >>>>>>> thoroughly-QA'd release. Also it might be nice to >>>> identify whatever >>>>>>> process problems led to this problem so that it can be >>>> avoided for >>>>>>> future releases. >>>>>>> >>>>>>> cheers, >>>>>>> Joe >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Talk mailing list >>>>>>> Talk@lists.collectionspace.org >>>>>>> >>>>>>> http://lists.collectionspace.org/mailman/listinfo/ >>>>>>> talk_lists.collecti >>>>>>> onspace.org >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Talk mailing list >>>>>> Talk@lists.collectionspace.org >>>>>> http://lists.collectionspace.org/mailman/listinfo/ >>>>>> talk_lists.collectio >>>>>> nspace.org >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Talk mailing list >>>>> Talk@lists.collectionspace.org >>>>> >>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectio >>>>> nspace.org >>>> >>>> >>>> _______________________________________________ >>>> Talk mailing list >>>> Talk@lists.collectionspace.org >>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.c >>>> ollectionspace.org >>>> >>> >>> >>> _______________________________________________ >>> Talk mailing list >>> Talk@lists.collectionspace.org >>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>> >> >> _______________________________________________ >> Talk mailing list >> Talk@lists.collectionspace.org >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

One more thing to add, to be complete, plus a question to Chris M: In v1.9 and v1.11 code, Chris has also begun to specify "domain" in her naming of configuration files in the Application layer, under: svcapp/tomcat-main/src/main/resources/tenants/{tenantname}/ . For example, under tenant/lifesci/, domain-collectionobject.xml is the file in which domain extension fields for the collectionobject record type are configured. In working with tenants here at UC Berkeley to date (v1.8), I've been adding a single App-layer configuration file named {tenantname}-tenant.xml (for example, ucjeps-tenant.xml), without breaking out separate files for fields defined in extension schemas for various record types. Chris, what's the proper way to do it in v1.9, v1.11 and beyond? Can implementors continue to add one configuration file with multiple <service-record-path> tags and 'section=" "' attributes in the <field> element to signify which schema the field comes from? Thanks, Rick On Sep 20, 2011, at 10:56 AM, Rick Jaffe wrote: > I left off one important detail in my rush to press. (This is a fast-moving thread!) In 1a., below, the tag in question comes from the tenant-bindings.delta.xml file> > The line should read: > > ... > a. In services/common/src/main/cspace/config/services/tenants/tenant-bindings.delta.xml : > <service:xmlContent namespaceURI="http://collectionspace.org/services/media/local/ucjeps" schemaLocation="http://collectionspace.org/services/media/local/ucjeps http://collectionspace.org/services/media/local/media_ucjeps.xsd" />, and ... > > - Rick > > --- > > Angela, Aron, all - > > Speaking to the first part of Aron's response, here's my (perhaps too-detailed) explanation. In short, there is no special place for a local schema. > > The local schema goes in the same place as any other extension schema, that being in this location in the services source code tree: > > services/{recordType, for example, collectionobject or loanin}/3rdparty/nuxeo-platform-{recordtype}-{tenantname}/src/main/resources/schemas/{extension schema name, such as {recordtype_tenantname}.xsd. > > A real example: > services/intake/3rdparty/nuxeo-platform-intake-havrc/src/main/resources/schemas/intake_havrc.xsd. > > Let me add several notes, at the risk of muddying things up: > > 1 The fact that the schema is a local, as opposed to domain, schema is determined by naming choices in several places. There is no intrinsic difference. The two important places that come to mind are: > > a. In services/common/src/main/cspace/config/services/tenants/ > <service:xmlContent namespaceURI="http://collectionspace.org/services/media/local/ucjeps" schemaLocation="http://collectionspace.org/services/media/local/ucjeps http://collectionspace.org/services/media/local/media_ucjeps.xsd" />, and > > b. In the Application layer {tenantname}-tenant.xml file (best to use the mini-build): > <services-record-path id="ucjeps">collectionobjects_ucjeps:http://collectionspace.org/services/collectionobject/local/ucjeps,collectionobjects_ucjeps</services-record-path> > > We often add text to the commented-out section at the head of the schema .xsd file itself, noting that the schema is a local or domain extension: > > CollectionObject schema (XSD) > > Entity : CollectionObject > Part : Local - UCJEPS (Extends Natural History)... > > 2. We've seemed to have dropped the "-cs-" bit in the part of the path "nuxeo-platform-{recordtype}-{tenantname}. The common schema is in a folder called "nuxeo-platform-cs-intake", but the extension schema is in a folder called "nuxeo-platform-intake-havrc." This is just a naming convention; either would work, as long as you identified the folder correctly in the build.xml file in the same folder. > > 3. For extension schemas, we haven't been adding a JAXB, as opposed to Nuxeo, schema. I don't know whether you'd have to if you planned to use a Java Client to hit the services; that's one of the things the JAXB schema handles. Aron has counseled me not to worry about it at this point. > > Enough for now, > Rick > > > On Sep 20, 2011, at 10:33 AM, Aron Roberts wrote: > >> On Tue, Sep 20, 2011 at 9:26 AM, Angela Spinazze <atspin@mindspring.com> wrote: >>> As I was talking with Joe S. last week, he >>> mentioned that he was trying to figure out where to put the WAC local >>> schema. Is there a designated place, for example, where the local schema >>> lives? Is that something that we cover in the documentation? >> >> This may be interpreted as either of two questions: >> >> 1. Where - within the services layer source code tree - does an >> implementer add an extension schema, in order to add custom fields? >> >> Rick and Jesse both have some recent notes on this process. Those can >> and should be turned into updated documentation; this may be one of >> our highest configuration doc priorities, project-wide. >> >> Richard has also done some work (in the v1.11/v1.12 space, I believe) >> toward simplifying the process, so that fewer steps would be involved >> in making an extension schema in the services. This work may at some >> point be reflected in the mini-build, as well. >> >> 2. Where can implementers contribute extension schemas they've >> developed, for sharing with other implementers and with the >> CollectionSpace project team? >> >> This appears to have been the question to which Patrick has responded here: >> >> On Tue, Sep 20, 2011 at 10:22 AM, Patrick Schmitz <pschmitz@berkeley.edu> wrote: >>> We have been talking about this, but have yet to put together a good spot >>> for this. I.e., it is on my plate which means it may wait a little... >> >> Aron >> >>> >>>> -----Original Message----- >>>> From: talk-bounces@lists.collectionspace.org >>>> [mailto:talk-bounces@lists.collectionspace.org] On Behalf Of >>>> Angela Spinazze >>>> Sent: Tuesday, September 20, 2011 9:26 AM >>>> To: Heather Hart >>>> Cc: CollectionSpace Talk List >>>> Subject: Re: [Talk] changed / deprecated links in 1.8 docs >>>> >>>> Thanks Heather, Aron, Jesse, and Rick for your work on >>>> getting this documentation sorted. >>>> >>>> One question for you all: As I was talking with Joe S. last >>>> week, he mentioned that he was trying to figure out where to >>>> put the WAC local schema. Is there a designated place, for >>>> example, where the local schema lives? Is that something >>>> that we cover in the documentation? >>>> >>>> Thanks, >>>> >>>> Angela >>>> >>>> On Sep 19, 2011, at 7:58 PM, Heather Hart wrote: >>>> >>>>> Hi Aron, >>>>> >>>>> Can you take a look at the updated multivalued field 1.8 >>>> pages and add >>>>> in the necessary details about the minibuild? >>>>> >>>>> >>>> http://wiki.collectionspace.org/display/CSPACE18/How+to+make+a+field+m >>>>> ultivalued >>>>> >>>>> Also a general review for accuracy as of 1.8 would be >>>> great. Rick has >>>>> given it a once over already. >>>>> >>>>> Thanks, >>>>> Heather >>>>> >>>>> -----Original Message----- >>>>> From: Aron Roberts [mailto:aronroberts@gmail.com] >>>>> Sent: Thursday, September 15, 2011 3:51 PM >>>>> To: Jesse Martinez; Heather Hart >>>>> Cc: CollectionSpace Talk List >>>>> Subject: Re: [Talk] changed / deprecated links in 1.8 docs >>>>> >>>>> *******PLEASE READ before 'mirroring' any docs******* >>>>> >>>>> Many of the key v1.8 docs are very different than their v1.9 >>>>> counterparts: >>>>> >>>>> * Some of the Installing CollectionSpace docs for v1.8 are (at >>>>> least) slightly different than their 1.9 counterparts. >>>>> >>>>> * At least one or two of the core Configuring CollectionSpace docs >>>>> differ substantially from their 1.9 counterparts, to >>>> reflect that the >>>>> app layer configuration changed to a new overlay structure in v1.9. >>>>> >>>>> Before doing any wholesale 'mirroring', it might be good to check a >>>>> chronological list of recently updated documents, and/or >>>> review which >>>>> documents should not be mirrored with both me and Kasper. >>>>> >>>>> Thanks, >>>>> Aron >>>>> >>>>> On Thu, Sep 15, 2011 at 3:08 PM, Jesse Martinez >>>>> <jmartinez@movingimage.us >>>>>> wrote: >>>>>> Heather, >>>>>> I think it's safe to mirror 1.9 onto 1.8 documentation >>>> granted that >>>>>> we be aware of any recent changes to 1.9. Although, I make the >>>>>> assumption that some changes may have occurred on both 1.8 >>>> as well as >>>>>> 1.9 so in that case it's moot. The trouble with links is a big one >>>>>> and if we can straighten it with 1.9 then we'd all be better off >>>>>> since we'll use >>>>>> 1.9 for 1.11 and so on. >>>>>> We just need to make the concerted effort to follow every lin on >>>>>> every page to make sure it's pointing in the right location. >>>>>> I'm not aware of any time out issues for me/us on the east >>>> coast. Was >>>>>> this recently? Did you also see issues with jira or any of >>>> our other >>>>>> services? >>>>>> - Jesse >>>>>> >>>>>> On Thu, Sep 15, 2011 at 3:26 PM, Heather Hart >>>> <hhart@bpoc.org> wrote: >>>>>>> >>>>>>> Hi Joe, >>>>>>> >>>>>>> One documentation issue always leads to several dozen >>>> more. This is >>>>>>> really two separate problems. >>>>>>> >>>>>>> First of all, these pages were not copied over because at >>>> the time >>>>>>> the 1.8 wiki was mirrored from UNRELEASED, we had not yet rescued >>>>>>> these pages from the main wiki where they were buried. If >>>> you look >>>>>>> at the 1.9 wiki space, these pages have been moved over >>>> and appear >>>>>>> in the heirarchy (left sidebar) under the appropriate page. >>>>>>> >>>>>>> Secondly, even though the pages exist where they should >>>> in the 1.9 >>>>>>> wiki, the links are still broken. The links did not travel well >>>>>>> because they are hard-linked (it is linked as a standard >>>> hyperlink: >>>>>>> http://wiki.collectionspace.org/display/collectionspace/How+to >>>>>>> +change >>>>>>> +the+definition+of+a+field+in+the+Services+configuration) >>>>>>> so when we "rescued" these pages, it also broke these links. >>>>>>> Unfortunately, the fluid tools can't tell us (as far as I >>>> know) when >>>>>>> we break hard links. >>>>>>> This is a great reminder to everyone to use the fluid tools when >>>>>>> editing the wiki pages. In this particular case, there is a child >>>>>>> pages macro that would work perfectly. Under normal >>>> circumstances it >>>>>>> is best to link to another cspace wiki page by using the search >>>>>>> function on the edit link screen. >>>>>>> >>>>>>> So, in terms of what we can and should do, the 1.8 wiki >>>> is in pretty >>>>>>> bad shape in general. Jesse, what do you think about re-mirroring >>>>>>> the >>>>>>> 1.9 wiki into 1.8? This is risky if people have been >>>> making changes >>>>>>> to the 1.8 pages. >>>>>>> The 1.9 wiki will include the "rescued" pages, but would >>>> not include >>>>>>> the fruits of our most recent documentation push (much of >>>> which may >>>>>>> apply to 1.8?). >>>>>>> >>>>>>> For now I am going to manually move these pages back into 1.8 and >>>>>>> then use the child macro instead of the hard-coded list >>>> so Joe can >>>>>>> continue his work. >>>>>>> I am having a bit of a time with this, since I keep getting >>>>>>> connection errors and "error retrieving breadcrumbs" problems. Is >>>>>>> anyone else having trouble with the wiki? >>>>>>> >>>>>>> Heather >>>>>>> ________________________________________ >>>>>>> From: talk-bounces@lists.collectionspace.org >>>>>>> [talk-bounces@lists.collectionspace.org] on behalf of Joe Slag >>>>>>> [joe@slagwerks.com] >>>>>>> Sent: Wednesday, September 14, 2011 8:10 AM >>>>>>> To: CollectionSpace Talk List >>>>>>> Subject: [Talk] changed / deprecated links in 1.8 docs >>>>>>> >>>>>>> I was just referring to >>>>>>> >>>>>>> http://wiki.collectionspace.org/display/CSPACE18/How+to+make+a >>>>>>> +field+ >>>>>>> multivalued and noticed that many of the details, under >>>> the heading >>>>>>> "Procedure step checklist", are links to pages that have >>>> been moved >>>>>>> or deprectated. >>>>>>> >>>>>>> For example, >>>>>>> >>>> http://wiki.collectionspace.org/display/collectionspace/How+to+edit >>>>>>> +t >>>>>>> he+definition+of+data+passed+into+and+out+of+a+field+in+the+UI >>>>>>> +schema >>>>>>> +file is linked to in step 2b. The top of that page says in red: >>>>>>> >>>>>>> REMOVE THIS PAGE - IT IS NOT ACCURATE. (FIELDS ARE NOT >>>> EDITED VIA >>>>>>> THE UI SCHEMA FILE) >>>>>>> >>>>>>> Many of the other pages seem to have been moved in a way >>>> that allows >>>>>>> confluence to make a good guess about their location, but still >>>>>>> presents an intermediate 'page moved' page. >>>>>>> >>>>>>> If this was just any old release I don't think it would be that >>>>>>> important, but I thought I'd mention it given 1.8's >>>> positioning as a >>>>>>> thoroughly-QA'd release. Also it might be nice to >>>> identify whatever >>>>>>> process problems led to this problem so that it can be >>>> avoided for >>>>>>> future releases. >>>>>>> >>>>>>> cheers, >>>>>>> Joe >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Talk mailing list >>>>>>> Talk@lists.collectionspace.org >>>>>>> >>>>>>> http://lists.collectionspace.org/mailman/listinfo/ >>>>>>> talk_lists.collecti >>>>>>> onspace.org >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Talk mailing list >>>>>> Talk@lists.collectionspace.org >>>>>> http://lists.collectionspace.org/mailman/listinfo/ >>>>>> talk_lists.collectio >>>>>> nspace.org >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Talk mailing list >>>>> Talk@lists.collectionspace.org >>>>> >>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectio >>>>> nspace.org >>>> >>>> >>>> _______________________________________________ >>>> Talk mailing list >>>> Talk@lists.collectionspace.org >>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.c >>>> ollectionspace.org >>>> >>> >>> >>> _______________________________________________ >>> Talk mailing list >>> Talk@lists.collectionspace.org >>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>> >> >> _______________________________________________ >> Talk mailing list >> Talk@lists.collectionspace.org >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

On Tue, Sep 20, 2011 at 12:32 PM, Rick Jaffe <rjaffe@berkeley.edu> wrote: > In working with tenants here at UC Berkeley to date (v1.8), I've been adding > a single App-layer configuration file named  {tenantname}-tenant.xml (for > example, ucjeps-tenant.xml), without breaking out separate files for fields > defined in extension schemas for various record types. Chris, what's the > proper way to do it in v1.9, v1.11 and beyond? Chris's doc on this is at: http://wiki.collectionspace.org/display/UNRELEASED/unified+collectionspace+config Basically, the monolithic cspace-config file has been broken up into (effectively) per-record chunks. This is almost certainly oversimplified, but: base-* files for configuring "out of the box" settings and domain-* files for adding new fields via extension schemas See her comments in the doc above, and in the discussion in the 2011-09-14 IRC chat, below, for best practices on where to put configuration changes: Aron -- (11:02:07 AM) aronr: csm22: do you have a moment, Chris? I'd like to get clear about best practices in using base-* v. domain-* in the v1.9 overlay structure, and update the overview doc on this if required. (11:02:28 AM) aronr: csm22: jmartinez is already (I believe) using v1.9, and he's likely getting to the app layer config, so this is timely (11:04:07 AM) csm22: hi aronr (11:04:45 AM) aronr: csm22: hi, Chris! if someone's adding fields, they go into a domain-*.xml doc in their tenant folder, correct? (11:05:19 AM) csm22: the overlay structure were based on the principles that the service layer does not support changes to the core. Therefore things should only ever be added into the domain overlay (11:05:40 AM) aronr: csm22: that makes perfect sense. (11:05:54 AM) csm22: this means that technically changes to fieldtypes, whether they are autocompletes etc are also not supported for core (11:06:07 AM) aronr: csm22: ok, that makes sense as well (11:06:46 AM) csm22: if you have to change the service layer core domain then fine overwrite the base-files as you wont be able to upgrade easily whatever happens (11:08:05 AM) aronr: csm22: if someone is, say, adding a second authority to the default 'person-person' (or whatever) to an autocomplete field in a common (standard) schema, how exactly should they do that? (11:08:58 AM) aronr: csm22: a) edit a base-* file in defaults folder (probably a very bad idea), b) copy that base-* file into their tenant folder and edit it there, c) copy that base-* file into their tenant folder and rename it as domain-*, or? (11:10:13 AM) csm22: currently that is not supported as you are not meant to change the functionality within the core - so you would have to overlay the base file - which isn't great. However, there is hope that a more dynamic approach will magically happen at some point (11:10:37 AM) csm22: domain files do not overlay base files - they just get appended to them ... (11:12:35 AM) csm22: so for the short answer - b (11:12:41 AM) aronr: csm22: yes :-) -- > Can implementors continue to > add one configuration file with multiple <service-record-path> tags and > 'section=" "' attributes in the <field> element to signify which schema the > field comes from? > Thanks, > Rick > > On Sep 20, 2011, at 10:56 AM, Rick Jaffe wrote: > > I left off one important detail in my rush to press. (This is a fast-moving > thread!) In 1a., below, the tag in question comes from the > tenant-bindings.delta.xml file> > The line should read: > > ... > a. In > services/common/src/main/cspace/config/services/tenants/tenant-bindings.delta.xml > : > <service:xmlContent > namespaceURI="http://collectionspace.org/services/media/local/ucjeps" > schemaLocation="http://collectionspace.org/services/media/local/ucjeps > http://collectionspace.org/services/media/local/media_ucjeps.xsd" />, and > ... > > - Rick > > --- > > Angela, Aron, all - > > Speaking to the first part of Aron's response, here's my (perhaps > too-detailed) explanation. In short, there is no special place for a local > schema. > > The local schema goes in the same place as any other extension schema, that > being in this location in the services source code tree: > > services/{recordType, for example, collectionobject or > loanin}/3rdparty/nuxeo-platform-{recordtype}-{tenantname}/src/main/resources/schemas/{extension > schema name, such as {recordtype_tenantname}.xsd. > > A real example: > services/intake/3rdparty/nuxeo-platform-intake-havrc/src/main/resources/schemas/intake_havrc.xsd. > > Let me add several notes, at the risk of muddying things up: > > 1 The fact that the schema is a local, as opposed to domain, schema is > determined by naming choices in several places. There is no intrinsic > difference. The two important places that come to mind are: > > a. In services/common/src/main/cspace/config/services/tenants/ > <service:xmlContent > namespaceURI="http://collectionspace.org/services/media/local/ucjeps" > schemaLocation="http://collectionspace.org/services/media/local/ucjeps > http://collectionspace.org/services/media/local/media_ucjeps.xsd" />, and > > b. In the Application layer {tenantname}-tenant.xml file (best to use the > mini-build): > <services-record-path > id="ucjeps">collectionobjects_ucjeps:http://collectionspace.org/services/collectionobject/local/ucjeps,collectionobjects_ucjeps</services-record-path> > > We often add text to the commented-out section at the head of the schema > .xsd file itself, noting that the schema is a local or domain extension: > > CollectionObject schema (XSD) > > Entity  : CollectionObject > Part    : Local - UCJEPS (Extends Natural History)... > > 2. We've seemed to have dropped the "-cs-" bit in the part of the path > "nuxeo-platform-{recordtype}-{tenantname}. The common schema is in a folder > called "nuxeo-platform-cs-intake",  but the extension schema is in a folder > called "nuxeo-platform-intake-havrc." This is just a naming convention; > either would work, as long as you identified the folder correctly in the > build.xml file in the same folder. > > 3. For extension schemas, we haven't been adding a JAXB, as opposed to > Nuxeo, schema. I don't know whether you'd have to if you planned to use a > Java Client to hit the services; that's one of the things the JAXB schema > handles. Aron has counseled me not to worry about it at this point. > > Enough for now, > Rick > > > On Sep 20, 2011, at 10:33 AM, Aron Roberts wrote: > > On Tue, Sep 20, 2011 at 9:26 AM, Angela Spinazze <atspin@mindspring.com> > wrote: > > As I was talking with Joe S. last week, he > > mentioned that he was trying to figure out where to put the WAC local > > schema. Is there a designated place, for example, where the local schema > > lives?  Is that something that we cover in the documentation? > > This may be interpreted as either of two questions: > > 1. Where - within the services layer source code tree - does an > > implementer add an extension schema, in order to add custom fields? > > Rick and Jesse both have some recent notes on this process.  Those can > > and should be turned into updated documentation; this may be one of > > our highest configuration doc priorities, project-wide. > > Richard has also done some work (in the v1.11/v1.12 space, I believe) > > toward simplifying the process, so that fewer steps would be involved > > in making an extension schema in the services.  This work may at some > > point be reflected in the mini-build, as well. > > 2. Where can implementers contribute extension schemas they've > > developed, for sharing with other implementers and with the > > CollectionSpace project team? > > This appears to have been the question to which Patrick has responded here: > > On Tue, Sep 20, 2011 at 10:22 AM, Patrick Schmitz <pschmitz@berkeley.edu> > wrote: > > We have been talking about this, but have yet to put together a good spot > > for this. I.e., it is on my plate which means it may wait a little... > > Aron > > > -----Original Message----- > > From: talk-bounces@lists.collectionspace.org > > [mailto:talk-bounces@lists.collectionspace.org] On Behalf Of > > Angela Spinazze > > Sent: Tuesday, September 20, 2011 9:26 AM > > To: Heather Hart > > Cc: CollectionSpace Talk List > > Subject: Re: [Talk] changed / deprecated links in 1.8 docs > > Thanks Heather, Aron, Jesse, and Rick for your work on > > getting this documentation sorted. > > One question for you all:  As I was talking with Joe S. last > > week, he mentioned that he was trying to figure out where to > > put the WAC local schema. Is there a designated place, for > > example, where the local schema lives?  Is that something > > that we cover in the documentation? > > Thanks, > > Angela > > On Sep 19, 2011, at 7:58 PM, Heather Hart wrote: > > Hi Aron, > > Can you take a look at the updated multivalued field 1.8 > > pages and add > > in the necessary details about the minibuild? > > > http://wiki.collectionspace.org/display/CSPACE18/How+to+make+a+field+m > > ultivalued > > Also a general review for accuracy as of 1.8 would be > > great. Rick has > > given it a once over already. > > Thanks, > > Heather > > -----Original Message----- > > From: Aron Roberts [mailto:aronroberts@gmail.com] > > Sent: Thursday, September 15, 2011 3:51 PM > > To: Jesse Martinez; Heather Hart > > Cc: CollectionSpace Talk List > > Subject: Re: [Talk] changed / deprecated links in 1.8 docs > > *******PLEASE READ before 'mirroring' any docs******* > > Many of the key v1.8 docs are very different than their v1.9 > > counterparts: > > * Some of the Installing CollectionSpace docs for v1.8 are (at > > least) slightly different than their 1.9 counterparts. > > * At least one or two of the core Configuring CollectionSpace docs > > differ substantially from their 1.9 counterparts, to > > reflect that the > > app layer configuration changed to a new overlay structure in v1.9. > > Before doing any wholesale 'mirroring', it might be good to check a > > chronological list of recently updated documents, and/or > > review which > > documents should not be mirrored with both me and Kasper. > > Thanks, > > Aron > > On Thu, Sep 15, 2011 at 3:08 PM, Jesse Martinez > > <jmartinez@movingimage.us > > wrote: > > Heather, > > I think it's safe to mirror 1.9 onto 1.8 documentation > > granted that > > we be aware of any recent changes to 1.9. Although, I make the > > assumption that some changes may have occurred on both 1.8 > > as well as > > 1.9 so in that case it's moot. The trouble with links is a big one > > and if we can straighten it with 1.9 then we'd all be better off > > since we'll use > > 1.9 for 1.11 and so on. > > We just need to make the concerted effort to follow every lin on > > every page to make sure it's pointing in the right location. > > I'm not aware of any time out issues for me/us on the east > > coast. Was > > this recently? Did you also see issues with jira or any of > > our other > > services? > > - Jesse > > On Thu, Sep 15, 2011 at 3:26 PM, Heather Hart > > <hhart@bpoc.org> wrote: > > Hi Joe, > > One documentation issue always leads to several dozen > > more. This is > > really two separate problems. > > First of all, these pages were not copied over because at > > the time > > the 1.8 wiki was mirrored from UNRELEASED, we had not yet rescued > > these pages from the main wiki where they were buried. If > > you look > > at the 1.9 wiki space, these pages have been moved over > > and appear > > in the heirarchy (left sidebar) under the appropriate page. > > Secondly, even though the pages exist where they should > > in the 1.9 > > wiki, the links are still broken. The links did not travel well > > because they are hard-linked (it is linked as a standard > > hyperlink: > > http://wiki.collectionspace.org/display/collectionspace/How+to > > +change > > +the+definition+of+a+field+in+the+Services+configuration) > > so when we "rescued" these pages, it also broke these links. > > Unfortunately, the fluid tools can't tell us (as far as I > > know) when > > we break hard links. > > This is a great reminder to everyone to use the fluid tools when > > editing the wiki pages. In this particular case, there is a child > > pages macro that would work perfectly. Under normal > > circumstances it > > is best to link to another cspace wiki page by using the search > > function on the edit link screen. > > So, in terms of what we can and should do, the 1.8 wiki > > is in pretty > > bad shape in general. Jesse, what do you think about re-mirroring > > the > > 1.9 wiki into 1.8? This is risky if people have been > > making changes > > to the 1.8 pages. > > The 1.9 wiki will include the "rescued" pages, but would > > not include > > the fruits of our most recent documentation push (much of > > which may > > apply to 1.8?). > > For now I am going to manually move these pages back into 1.8 and > > then use the child macro instead of the hard-coded list > > so Joe can > > continue his work. > > I am having a bit of a time with this, since I keep getting > > connection errors and "error retrieving breadcrumbs" problems. Is > > anyone else having trouble with the wiki? > > Heather > > ________________________________________ > > From: talk-bounces@lists.collectionspace.org > > [talk-bounces@lists.collectionspace.org] on behalf of Joe Slag > > [joe@slagwerks.com] > > Sent: Wednesday, September 14, 2011 8:10 AM > > To: CollectionSpace Talk List > > Subject: [Talk] changed / deprecated links in 1.8 docs > > I was just referring to > > http://wiki.collectionspace.org/display/CSPACE18/How+to+make+a > > +field+ > > multivalued and noticed that many of the details, under > > the heading > > "Procedure step checklist", are links to pages that have > > been moved > > or deprectated. > > For example, > > http://wiki.collectionspace.org/display/collectionspace/How+to+edit > > +t > > he+definition+of+data+passed+into+and+out+of+a+field+in+the+UI > > +schema > > +file is linked to in step 2b. The top of that page says in red: > > REMOVE THIS PAGE - IT IS  NOT ACCURATE. (FIELDS ARE NOT > > EDITED VIA > > THE UI SCHEMA FILE) > > Many of the other pages seem to have been moved in a way > > that allows > > confluence to make a good guess about their location, but still > > presents an intermediate 'page moved' page. > > If this was just any old release I don't think it would be that > > important, but I thought I'd mention it given 1.8's > > positioning as a > > thoroughly-QA'd release. Also it might be nice to > > identify whatever > > process problems led to this problem so that it can be > > avoided for > > future releases. > > cheers, > > Joe > > _______________________________________________ > > Talk mailing list > > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/ > > talk_lists.collecti > > onspace.org > > > _______________________________________________ > > Talk mailing list > > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/ > > talk_lists.collectio > > nspace.org > > > > _______________________________________________ > > Talk mailing list > > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectio > > nspace.org > > > _______________________________________________ > > Talk mailing list > > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.c > > ollectionspace.org > > > > _______________________________________________ > > Talk mailing list > > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > > > _______________________________________________ > > Talk mailing list > > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > >