From: Lynette R. <el...@cs...> - 2007-05-18 02:46:54
|
Here is the summary of the users' comments... - Are previous versions for viewing only? =20 All said yes. - Do you need to be able to rollback to previous versions? Example, a previous version will be copied and saved as the latest version. All = changes from the previous version to date will be maintained between the = original previous version and the new copied latest version. =20 All said yes. - Is an audit trail needed? Specifically... o Do you need a log message for each change?=20 o Do you need version numbers?=20 o Do you need to be able to assign the version numbers yourself to = control indicators of major versus minor releases (1.1, 1.2, 2.0 etc.) Everyone wanted a date-time stamp. Everyone wanted some kind of indicator about who made the change. Everyone liked the idea of a log message. Everyone liked the idea of version numbers. Log messages and version numbers weren't seen as a strong requirement Lynette -----Original Message----- From: Lynette Rayle=20 Sent: Tuesday, May 15, 2007 9:25 PM To: 'fez...@li...' Subject: RE: [Fez-developers] [Fwd: Re: FW: Thoughts on Versioning] That all sounds good to me. I have requested use case information from several groups that are going to be the first users of our system. I = should have that by our end of day tomorrow and will forward you summaries of = their comments. Lynette =20 -----Original Message----- From: fez...@li... [mailto:fez...@li...] On Behalf Of = Matthew Smith Sent: Monday, May 14, 2007 8:09 PM To: fez...@li... Subject: [Fez-developers] [Fwd: Re: FW: Thoughts on Versioning] I had the fez-developers address wrong! -------- Original Message -------- Subject: Re: FW: Thoughts on Versioning Date: Tue, 15 May 2007 09:01:07 +1000 From: Matthew Smith <m....@li...> To: Lynette Rayle <el...@cs...> CC: fez...@so..., Christiaan Kortekaas <c.k...@li...>, Lachlan Kuhn <l....@li...> References: <04745CBF7A8C024C9267D85521D18BEB016420BB@EXCHANGE1.cs.cornell.edu> Lynette, The fez developers list seems to be MIA at the moment :-( So the person with the right privileges can click on a record then view a version history which is similar to the PREMIS event log. They would be able to select a version on this list and view the record as it was at this version. They could then run a rollback workflow to cause a new version of the record to be created which is the same as the selected old version. I think fedora versioning is the way to go and maybe we could tie the PREMIS events to the fedora versions so that they can be used together. I have been wanting to add something to the workflows to allow the system to prompt for a rationale to be logged against each change to a record including deletion. We are also hoping to implement a kind of trash can thing in Fez so that records have a second chance before being purged forever. Matt Lynette Rayle wrote: > The primary use case to date has been to be able to track changes over time. > But I can only imagine that at some point in time, someone is going to = want > to revert to a previous version. To maintain a complete history of = the > version changes, I prefer that a previous version is copied and saved = as the > latest version. That maintains any changes that were made in between. >=20 > Lynette >=20 >=20 > -----Original Message----- > From: Matthew Smith [mailto:m....@li...]=20 > Sent: Sunday, May 13, 2007 7:57 PM > To: Lynette Rayle; fez...@so... > Subject: Re: FW: Thoughts on Versioning >=20 > Hi >=20 > I think the UI proposal makes sense. >=20 > I would lean towards using fedora versioning and trust that they will > make some improvements in performance there. It would be a matter of > supplying a user interface to list previous versions. >=20 > The 'succeeds' stuff is something we carried over from ePrints perhaps > out of folly but wanting to lessen the alien-ness of going from = ePrints > to eSpace for some of our 'champions of the cause' here at UQ. It is > just a way to make a copy of a record but keep a track of where the = copy > came from and what the intention of the copy is. I don't like it how > older versions could be confused with newer versions though. >=20 > What are the use cases for the versions? Are they just for looking = at? > Is there an audit process that this is for? Is it that there is a > rollback functionality required? >=20 > Matt >=20 >=20 > Christiaan Kortekaas wrote: >> ------ Forwarded Message >> *From: *Lynette Rayle <el...@cs...> >> *Date: *Fri, 11 May 2007 17:25:16 -0400 >> *To: *Christiaan Kortekaas <c.k...@li...> >> *Conversation: *Thoughts on Versioning >> *Subject: *Thoughts on Versioning >> >> Hi Christiaan, >> =20 >> I have two tracks that my thoughts on versioning go down. One = involves >> Fedora versioning of the datastreams within a record. The other = involves >> having a separate record for each version that references the = previous >> record using the Succeeds field. >> =20 >> How these might look... >> =20 >> Datastream versioning: >> =20 >> When the user selects the edit icon for a record, the attached files = and >> related links are listed at the bottom. See the attached >> VersioningInObject.html file to see proposed changes to this area to >> allow for updating with a new version. (I didn't take the time to >> resolve all css issues, but you'll get the basic idea.) In Fedora = 2.1, >> I would use the upload process to get the new version of the file = into >> fedora and then call modifyDatastreamByReference passing the internal >> URI returned from the upload process as the location. I believe that >> Fedora 2.2 supports uploading as part of the = modifyDatastreamByReference >> call, but I haven't done anything with 2.2 yet, so I don't know that = for >> sure. The only trick is that the mimetype of the new file must be >> compatible with the mimetype of the existing file. For example, you = can >> replace an image with another image, but you cannot replace an image >> with a text file. >> =20 >> The remaining issue is how to provide the user access to previous >> versions? Fedora handles the request for a specific version by >> receiving a date with API calls. The latest values for datastreams >> preceding and including that date are returned from Fedora. In our = app, >> dates of major changes were tracked. The user could see a list of = these >> major changes and select one. The date associated with the major = change >> was used to request information from the Fedora object. One option = for >> Fez would be to include links in the Detailed History screen that = would >> do a View Record with values from the date associated with the = selected >> history entry. >> =20 >> Succeeds versioning: >> =20 >> Make one of the security options whether or not to "enforce version >> control". It can be set at the community or collection levels, = perhaps >> at the record level. If "enforce version control" is off, everything >> operates exactly as Fez does today. If "enforce version control" is = on, >> succeeds is used to establish versions. =20 >> =20 >> Actions: >> - EDIT current version: When edit is selected for the most current >> version, the current record (referred to as original record) is = cloned. >> The new clone record is automatically assigned a Succeeds value of = the >> original record's pid. The user edits the new clone record. The >> original record remains published and unchanged. When the clone = record >> is published, it becomes the current version. >> =20 >> - EDIT previous versions: Not allowed. >> =20 >> - CLONE current version: Creates a new record outside of the current >> version chain. >> - CLONE previous versions: Creates a new record outside of the = current >> version chain. >> =20 >> - There needs to be a way to replace the current version (original >> record) with an older version. The older version would be cloned and >> the Succeeds field would be set to the pid of the original record. = I'm >> not sure how best to represent this in the UI. I'd have to think = about >> this some more. >> =20 >> - Add Save as a state in the EDIT (Update Record) workflow. The = record >> would remain available in the contributor/editor's My Fez until = Submit >> for Approval is selected from the EDIT screen or through My Fez. EDIT = of >> an unpublished/saved record would not result in the creation of a new >> record. The unpublished/saved record was created through cloning = when >> the latest published version was edited. (Any particular reason why >> Save isn't part of Fez? Am I missing something here that makes this >> untenable? I know that our contributors/editors are going to want to >> tweak things before sending them to the approver.) =20 >> =20 >> There is the potential with Succeeds versioning to have multiple = objects >> succeeding the same record. The scenario that would cause this is = one >> user EDITs the current version which creates a clone that succeeds = the >> current version. Before the edits are completed and the record is >> published, another user EDITs the current version which remains the = same >> until the new clone is published. So, this EDIT clones the same = object >> as the other EDIT and sets up the succeeds field to the same record. = >> =20 >> How best to prevent this? Hmmm... that is the question. Checkout of >> records is one option. Another option would be to include a = date-time >> stamp when the clone occurred. The date-time stamp could be used to = see >> if the current version at publish time is the same current version = when >> the clone was performed. A warning could be displayed if they don't >> match. If the user forces the publish anyway, the succeeds field = will >> be updated to the current version at the time of publish to maintain = the >> correct succeeds chain. >> =20 >> I haven't played with Succeeds because it does not function in the >> release that I have installed, so here are some of my assumptions = about >> how it currently works. >> =20 >> - All records are available through search. >> - Users are expected to establish logical succeeds relationships. = Fez >> does nothing to control this relationship. >> - Succeeds goes in one direction... more recent record succeeds an >> older record. >> - A record can only succeed one record. >> - A record can be succeeded by any number of records. (Although I'm = not >> sure I can think of a use case for this myself especially in the = context >> of versioning.) >> - When a record is viewed, the succeeds chain is shown in both >> directions. That is, even though the record only explicitly states = the >> record it succeeds, the record(s) that has a relationship saying it >> succeeds this record would also be shown. >> =20 >> =20 >> =20 >> Thoughts on the two options... >> =20 >> Datastream versioning is known to negatively effect performance as = the >> size of the object increases. The advantage of datastream versioning = is >> that there will be a single Fedora object to represent a single >> conceptual record. Also, any improvements to Fedora versioning would >> improve Fez versioning as well. Seems like you would loose full-text >> searching for previous versions, but I'm not familiar enough with Fez >> search to state that with certainty. >> =20 >> Search for Succeeds versioning would find previous versions as well = as >> the current version. Which may or may not be desirable for an >> individual search. Enhancements to search could have the option to >> search current versions only. How is Succeeds currently being used? >> Would use for versioning present some conceptual problems with = current > use? >> =20 >> =20 >> Let me know what your thoughts are on this. >> =20 >> =20 >> Lynette >> >> >> ------ End of Forwarded Message >=20 |
From: Lynette R. <el...@cs...> - 2007-07-03 01:35:50
|
I wanted to touch base to see if any of you have had further thoughts on versioning. Does it sound like something you'll be able to put into Fez = 1.4? Lynette -----Original Message----- From: fez...@li... [mailto:fez...@li...] On Behalf Of = Lynette Rayle Sent: Thursday, May 17, 2007 10:46 PM To: fez...@li... Subject: Re: [Fez-developers] Thoughts on Versioning Here is the summary of the users' comments... - Are previous versions for viewing only? =20 All said yes. - Do you need to be able to rollback to previous versions? Example, a previous version will be copied and saved as the latest version. All = changes from the previous version to date will be maintained between the = original previous version and the new copied latest version. =20 All said yes. - Is an audit trail needed? Specifically... o Do you need a log message for each change?=20 o Do you need version numbers?=20 o Do you need to be able to assign the version numbers yourself to = control indicators of major versus minor releases (1.1, 1.2, 2.0 etc.) Everyone wanted a date-time stamp. Everyone wanted some kind of indicator about who made the change. Everyone liked the idea of a log message. Everyone liked the idea of version numbers. Log messages and version numbers weren't seen as a strong requirement Lynette -----Original Message----- From: Lynette Rayle=20 Sent: Tuesday, May 15, 2007 9:25 PM To: 'fez...@li...' Subject: RE: [Fez-developers] [Fwd: Re: FW: Thoughts on Versioning] That all sounds good to me. I have requested use case information from several groups that are going to be the first users of our system. I = should have that by our end of day tomorrow and will forward you summaries of = their comments. Lynette =20 -----Original Message----- From: fez...@li... [mailto:fez...@li...] On Behalf Of = Matthew Smith Sent: Monday, May 14, 2007 8:09 PM To: fez...@li... Subject: [Fez-developers] [Fwd: Re: FW: Thoughts on Versioning] I had the fez-developers address wrong! -------- Original Message -------- Subject: Re: FW: Thoughts on Versioning Date: Tue, 15 May 2007 09:01:07 +1000 From: Matthew Smith <m....@li...> To: Lynette Rayle <el...@cs...> CC: fez...@so..., Christiaan Kortekaas <c.k...@li...>, Lachlan Kuhn <l....@li...> References: <04745CBF7A8C024C9267D85521D18BEB016420BB@EXCHANGE1.cs.cornell.edu> Lynette, The fez developers list seems to be MIA at the moment :-( So the person with the right privileges can click on a record then view a version history which is similar to the PREMIS event log. They would be able to select a version on this list and view the record as it was at this version. They could then run a rollback workflow to cause a new version of the record to be created which is the same as the selected old version. I think fedora versioning is the way to go and maybe we could tie the PREMIS events to the fedora versions so that they can be used together. I have been wanting to add something to the workflows to allow the system to prompt for a rationale to be logged against each change to a record including deletion. We are also hoping to implement a kind of trash can thing in Fez so that records have a second chance before being purged forever. Matt Lynette Rayle wrote: > The primary use case to date has been to be able to track changes over time. > But I can only imagine that at some point in time, someone is going to = want > to revert to a previous version. To maintain a complete history of = the > version changes, I prefer that a previous version is copied and saved = as the > latest version. That maintains any changes that were made in between. >=20 > Lynette >=20 >=20 > -----Original Message----- > From: Matthew Smith [mailto:m....@li...]=20 > Sent: Sunday, May 13, 2007 7:57 PM > To: Lynette Rayle; fez...@so... > Subject: Re: FW: Thoughts on Versioning >=20 > Hi >=20 > I think the UI proposal makes sense. >=20 > I would lean towards using fedora versioning and trust that they will > make some improvements in performance there. It would be a matter of > supplying a user interface to list previous versions. >=20 > The 'succeeds' stuff is something we carried over from ePrints perhaps > out of folly but wanting to lessen the alien-ness of going from = ePrints > to eSpace for some of our 'champions of the cause' here at UQ. It is > just a way to make a copy of a record but keep a track of where the = copy > came from and what the intention of the copy is. I don't like it how > older versions could be confused with newer versions though. >=20 > What are the use cases for the versions? Are they just for looking = at? > Is there an audit process that this is for? Is it that there is a > rollback functionality required? >=20 > Matt >=20 >=20 > Christiaan Kortekaas wrote: >> ------ Forwarded Message >> *From: *Lynette Rayle <el...@cs...> >> *Date: *Fri, 11 May 2007 17:25:16 -0400 >> *To: *Christiaan Kortekaas <c.k...@li...> >> *Conversation: *Thoughts on Versioning >> *Subject: *Thoughts on Versioning >> >> Hi Christiaan, >> =20 >> I have two tracks that my thoughts on versioning go down. One = involves >> Fedora versioning of the datastreams within a record. The other = involves >> having a separate record for each version that references the = previous >> record using the Succeeds field. >> =20 >> How these might look... >> =20 >> Datastream versioning: >> =20 >> When the user selects the edit icon for a record, the attached files = and >> related links are listed at the bottom. See the attached >> VersioningInObject.html file to see proposed changes to this area to >> allow for updating with a new version. (I didn't take the time to >> resolve all css issues, but you'll get the basic idea.) In Fedora = 2.1, >> I would use the upload process to get the new version of the file = into >> fedora and then call modifyDatastreamByReference passing the internal >> URI returned from the upload process as the location. I believe that >> Fedora 2.2 supports uploading as part of the = modifyDatastreamByReference >> call, but I haven't done anything with 2.2 yet, so I don't know that = for >> sure. The only trick is that the mimetype of the new file must be >> compatible with the mimetype of the existing file. For example, you = can >> replace an image with another image, but you cannot replace an image >> with a text file. >> =20 >> The remaining issue is how to provide the user access to previous >> versions? Fedora handles the request for a specific version by >> receiving a date with API calls. The latest values for datastreams >> preceding and including that date are returned from Fedora. In our = app, >> dates of major changes were tracked. The user could see a list of = these >> major changes and select one. The date associated with the major = change >> was used to request information from the Fedora object. One option = for >> Fez would be to include links in the Detailed History screen that = would >> do a View Record with values from the date associated with the = selected >> history entry. >> =20 >> Succeeds versioning: >> =20 >> Make one of the security options whether or not to "enforce version >> control". It can be set at the community or collection levels, = perhaps >> at the record level. If "enforce version control" is off, everything >> operates exactly as Fez does today. If "enforce version control" is = on, >> succeeds is used to establish versions. =20 >> =20 >> Actions: >> - EDIT current version: When edit is selected for the most current >> version, the current record (referred to as original record) is = cloned. >> The new clone record is automatically assigned a Succeeds value of = the >> original record's pid. The user edits the new clone record. The >> original record remains published and unchanged. When the clone = record >> is published, it becomes the current version. >> =20 >> - EDIT previous versions: Not allowed. >> =20 >> - CLONE current version: Creates a new record outside of the current >> version chain. >> - CLONE previous versions: Creates a new record outside of the = current >> version chain. >> =20 >> - There needs to be a way to replace the current version (original >> record) with an older version. The older version would be cloned and >> the Succeeds field would be set to the pid of the original record. = I'm >> not sure how best to represent this in the UI. I'd have to think = about >> this some more. >> =20 >> - Add Save as a state in the EDIT (Update Record) workflow. The = record >> would remain available in the contributor/editor's My Fez until = Submit >> for Approval is selected from the EDIT screen or through My Fez. EDIT = of >> an unpublished/saved record would not result in the creation of a new >> record. The unpublished/saved record was created through cloning = when >> the latest published version was edited. (Any particular reason why >> Save isn't part of Fez? Am I missing something here that makes this >> untenable? I know that our contributors/editors are going to want to >> tweak things before sending them to the approver.) =20 >> =20 >> There is the potential with Succeeds versioning to have multiple = objects >> succeeding the same record. The scenario that would cause this is = one >> user EDITs the current version which creates a clone that succeeds = the >> current version. Before the edits are completed and the record is >> published, another user EDITs the current version which remains the = same >> until the new clone is published. So, this EDIT clones the same = object >> as the other EDIT and sets up the succeeds field to the same record. = >> =20 >> How best to prevent this? Hmmm... that is the question. Checkout of >> records is one option. Another option would be to include a = date-time >> stamp when the clone occurred. The date-time stamp could be used to = see >> if the current version at publish time is the same current version = when >> the clone was performed. A warning could be displayed if they don't >> match. If the user forces the publish anyway, the succeeds field = will >> be updated to the current version at the time of publish to maintain = the >> correct succeeds chain. >> =20 >> I haven't played with Succeeds because it does not function in the >> release that I have installed, so here are some of my assumptions = about >> how it currently works. >> =20 >> - All records are available through search. >> - Users are expected to establish logical succeeds relationships. = Fez >> does nothing to control this relationship. >> - Succeeds goes in one direction... more recent record succeeds an >> older record. >> - A record can only succeed one record. >> - A record can be succeeded by any number of records. (Although I'm = not >> sure I can think of a use case for this myself especially in the = context >> of versioning.) >> - When a record is viewed, the succeeds chain is shown in both >> directions. That is, even though the record only explicitly states = the >> record it succeeds, the record(s) that has a relationship saying it >> succeeds this record would also be shown. >> =20 >> =20 >> =20 >> Thoughts on the two options... >> =20 >> Datastream versioning is known to negatively effect performance as = the >> size of the object increases. The advantage of datastream versioning = is >> that there will be a single Fedora object to represent a single >> conceptual record. Also, any improvements to Fedora versioning would >> improve Fez versioning as well. Seems like you would loose full-text >> searching for previous versions, but I'm not familiar enough with Fez >> search to state that with certainty. >> =20 >> Search for Succeeds versioning would find previous versions as well = as >> the current version. Which may or may not be desirable for an >> individual search. Enhancements to search could have the option to >> search current versions only. How is Succeeds currently being used? >> Would use for versioning present some conceptual problems with = current > use? >> =20 >> =20 >> Let me know what your thoughts are on this. >> =20 >> =20 >> Lynette >> >> >> ------ End of Forwarded Message >=20 -------------------------------------------------------------------------= This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Fez-developers mailing list Fez...@li... https://lists.sourceforge.net/lists/listinfo/fez-developers |
From: Matthew S. <yo....@gm...> - 2007-07-19 04:05:27
|
Hi Lynette, I'm sorry about the lack of response from us on this question. Our current condition is that development is being driven by our various funding sources which don't have a requirement for versioning (yet). I think we mentioned before about a new RQF framework that is being implemented in Australia for Universities. We all have fires under our chairs trying to get things in place for that! Don't lose hope though, part of our funding is to foster an open-source community around the software and we are trying to incorporate things that Fez users are interested in such as your request for versioning and other's requests for multilingual support. In the mean-time we're happy to work with you or any of your programmers who are implementing anything along these lines. Matt On 7/3/07, Lynette Rayle <el...@cs...> wrote: > > I wanted to touch base to see if any of you have had further thoughts on > versioning. Does it sound like something you'll be able to put into Fez 1.4? > > Lynette > > -----Original Message----- > From: fez...@li... > [mailto:fez...@li...] On Behalf Of Lynette > Rayle > Sent: Thursday, May 17, 2007 10:46 PM > To: fez...@li... > Subject: Re: [Fez-developers] Thoughts on Versioning > > Here is the summary of the users' comments... > > - Are previous versions for viewing only? > > All said yes. > > - Do you need to be able to rollback to previous versions? Example, a > previous version will be copied and saved as the latest version. All changes > from the previous version to date will be maintained between the original > previous version and the new copied latest version. > > All said yes. > > - Is an audit trail needed? Specifically... > o Do you need a log message for each change? > o Do you need version numbers? > o Do you need to be able to assign the version numbers yourself to control > indicators of major versus minor releases (1.1, 1.2, 2.0 etc.) > > Everyone wanted a date-time stamp. > Everyone wanted some kind of indicator about who made the change. > Everyone liked the idea of a log message. > Everyone liked the idea of version numbers. > Log messages and version numbers weren't seen as a strong requirement > > Lynette > > -----Original Message----- > From: Lynette Rayle > Sent: Tuesday, May 15, 2007 9:25 PM > To: 'fez...@li...' > Subject: RE: [Fez-developers] [Fwd: Re: FW: Thoughts on Versioning] > > That all sounds good to me. I have requested use case information from > several groups that are going to be the first users of our system. I should > have that by our end of day tomorrow and will forward you summaries of their > comments. > > Lynette > > -----Original Message----- > From: fez...@li... > [mailto:fez...@li...] On Behalf Of Matthew > Smith > Sent: Monday, May 14, 2007 8:09 PM > To: fez...@li... > Subject: [Fez-developers] [Fwd: Re: FW: Thoughts on Versioning] > > I had the fez-developers address wrong! > > -------- Original Message -------- > Subject: Re: FW: Thoughts on Versioning > Date: Tue, 15 May 2007 09:01:07 +1000 > From: Matthew Smith <m....@li...> > To: Lynette Rayle <el...@cs...> > CC: fez...@so..., Christiaan Kortekaas > <c.k...@li...>, Lachlan Kuhn <l....@li...> > References: > <04745CBF7A8C024C9267D85521D18BEB016420BB@EXCHANGE1.cs.cornell.edu> > > Lynette, > > The fez developers list seems to be MIA at the moment :-( > > So the person with the right privileges can click on a record then view > a version history which is similar to the PREMIS event log. They would > be able to select a version on this list and view the record as it was > at this version. They could then run a rollback workflow to cause a new > version of the record to be created which is the same as the selected > old version. > > I think fedora versioning is the way to go and maybe we could tie the > PREMIS events to the fedora versions so that they can be used together. > > I have been wanting to add something to the workflows to allow the > system to prompt for a rationale to be logged against each change to a > record including deletion. We are also hoping to implement a kind of > trash can thing in Fez so that records have a second chance before being > purged forever. > > Matt > > > Lynette Rayle wrote: > > The primary use case to date has been to be able to track changes over > time. > > But I can only imagine that at some point in time, someone is going to want > > to revert to a previous version. To maintain a complete history of the > > version changes, I prefer that a previous version is copied and saved as > the > > latest version. That maintains any changes that were made in between. > > > > Lynette > > > > > > -----Original Message----- > > From: Matthew Smith [mailto:m....@li...] > > Sent: Sunday, May 13, 2007 7:57 PM > > To: Lynette Rayle; fez...@so... > > Subject: Re: FW: Thoughts on Versioning > > > > Hi > > > > I think the UI proposal makes sense. > > > > I would lean towards using fedora versioning and trust that they will > > make some improvements in performance there. It would be a matter of > > supplying a user interface to list previous versions. > > > > The 'succeeds' stuff is something we carried over from ePrints perhaps > > out of folly but wanting to lessen the alien-ness of going from ePrints > > to eSpace for some of our 'champions of the cause' here at UQ. It is > > just a way to make a copy of a record but keep a track of where the copy > > came from and what the intention of the copy is. I don't like it how > > older versions could be confused with newer versions though. > > > > What are the use cases for the versions? Are they just for looking at? > > Is there an audit process that this is for? Is it that there is a > > rollback functionality required? > > > > Matt > > > > > > Christiaan Kortekaas wrote: > >> ------ Forwarded Message > >> *From: *Lynette Rayle <el...@cs...> > >> *Date: *Fri, 11 May 2007 17:25:16 -0400 > >> *To: *Christiaan Kortekaas <c.k...@li...> > >> *Conversation: *Thoughts on Versioning > >> *Subject: *Thoughts on Versioning > >> > >> Hi Christiaan, > >> > >> I have two tracks that my thoughts on versioning go down. One involves > >> Fedora versioning of the datastreams within a record. The other involves > >> having a separate record for each version that references the previous > >> record using the Succeeds field. > >> > >> How these might look... > >> > >> Datastream versioning: > >> > >> When the user selects the edit icon for a record, the attached files and > >> related links are listed at the bottom. See the attached > >> VersioningInObject.html file to see proposed changes to this area to > >> allow for updating with a new version. (I didn't take the time to > >> resolve all css issues, but you'll get the basic idea.) In Fedora 2.1, > >> I would use the upload process to get the new version of the file into > >> fedora and then call modifyDatastreamByReference passing the internal > >> URI returned from the upload process as the location. I believe that > >> Fedora 2.2 supports uploading as part of the modifyDatastreamByReference > >> call, but I haven't done anything with 2.2 yet, so I don't know that for > >> sure. The only trick is that the mimetype of the new file must be > >> compatible with the mimetype of the existing file. For example, you can > >> replace an image with another image, but you cannot replace an image > >> with a text file. > >> > >> The remaining issue is how to provide the user access to previous > >> versions? Fedora handles the request for a specific version by > >> receiving a date with API calls. The latest values for datastreams > >> preceding and including that date are returned from Fedora. In our app, > >> dates of major changes were tracked. The user could see a list of these > >> major changes and select one. The date associated with the major change > >> was used to request information from the Fedora object. One option for > >> Fez would be to include links in the Detailed History screen that would > >> do a View Record with values from the date associated with the selected > >> history entry. > >> > >> Succeeds versioning: > >> > >> Make one of the security options whether or not to "enforce version > >> control". It can be set at the community or collection levels, perhaps > >> at the record level. If "enforce version control" is off, everything > >> operates exactly as Fez does today. If "enforce version control" is on, > >> succeeds is used to establish versions. > >> > >> Actions: > >> - EDIT current version: When edit is selected for the most current > >> version, the current record (referred to as original record) is cloned. > >> The new clone record is automatically assigned a Succeeds value of the > >> original record's pid. The user edits the new clone record. The > >> original record remains published and unchanged. When the clone record > >> is published, it becomes the current version. > >> > >> - EDIT previous versions: Not allowed. > >> > >> - CLONE current version: Creates a new record outside of the current > >> version chain. > >> - CLONE previous versions: Creates a new record outside of the current > >> version chain. > >> > >> - There needs to be a way to replace the current version (original > >> record) with an older version. The older version would be cloned and > >> the Succeeds field would be set to the pid of the original record. I'm > >> not sure how best to represent this in the UI. I'd have to think about > >> this some more. > >> > >> - Add Save as a state in the EDIT (Update Record) workflow. The record > >> would remain available in the contributor/editor's My Fez until Submit > >> for Approval is selected from the EDIT screen or through My Fez. EDIT of > >> an unpublished/saved record would not result in the creation of a new > >> record. The unpublished/saved record was created through cloning when > >> the latest published version was edited. (Any particular reason why > >> Save isn't part of Fez? Am I missing something here that makes this > >> untenable? I know that our contributors/editors are going to want to > >> tweak things before sending them to the approver.) > >> > >> There is the potential with Succeeds versioning to have multiple objects > >> succeeding the same record. The scenario that would cause this is one > >> user EDITs the current version which creates a clone that succeeds the > >> current version. Before the edits are completed and the record is > >> published, another user EDITs the current version which remains the same > >> until the new clone is published. So, this EDIT clones the same object > >> as the other EDIT and sets up the succeeds field to the same record. > >> > >> How best to prevent this? Hmmm... that is the question. Checkout of > >> records is one option. Another option would be to include a date-time > >> stamp when the clone occurred. The date-time stamp could be used to see > >> if the current version at publish time is the same current version when > >> the clone was performed. A warning could be displayed if they don't > >> match. If the user forces the publish anyway, the succeeds field will > >> be updated to the current version at the time of publish to maintain the > >> correct succeeds chain. > >> > >> I haven't played with Succeeds because it does not function in the > >> release that I have installed, so here are some of my assumptions about > >> how it currently works. > >> > >> - All records are available through search. > >> - Users are expected to establish logical succeeds relationships. Fez > >> does nothing to control this relationship. > >> - Succeeds goes in one direction... more recent record succeeds an > >> older record. > >> - A record can only succeed one record. > >> - A record can be succeeded by any number of records. (Although I'm not > >> sure I can think of a use case for this myself especially in the context > >> of versioning.) > >> - When a record is viewed, the succeeds chain is shown in both > >> directions. That is, even though the record only explicitly states the > >> record it succeeds, the record(s) that has a relationship saying it > >> succeeds this record would also be shown. > >> > >> > >> > >> Thoughts on the two options... > >> > >> Datastream versioning is known to negatively effect performance as the > >> size of the object increases. The advantage of datastream versioning is > >> that there will be a single Fedora object to represent a single > >> conceptual record. Also, any improvements to Fedora versioning would > >> improve Fez versioning as well. Seems like you would loose full-text > >> searching for previous versions, but I'm not familiar enough with Fez > >> search to state that with certainty. > >> > >> Search for Succeeds versioning would find previous versions as well as > >> the current version. Which may or may not be desirable for an > >> individual search. Enhancements to search could have the option to > >> search current versions only. How is Succeeds currently being used? > >> Would use for versioning present some conceptual problems with current > > use? > >> > >> > >> Let me know what your thoughts are on this. > >> > >> > >> Lynette > >> > >> > >> ------ End of Forwarded Message > > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Fez-developers mailing list > Fez...@li... > https://lists.sourceforge.net/lists/listinfo/fez-developers > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Fez-developers mailing list > Fez...@li... > https://lists.sourceforge.net/lists/listinfo/fez-developers > |