Hi Bernadette

This is a tricky problem. We also have this problem with search keys, though we have recently split search keys into ids with namespaces to try to avoid this problem. We will probably also roll this solution out to XSDs and workflows.

The namespaces we have the namespace ‘core’ for fez search keys that every fez should have. The search keys you would create in your own fez will have the namespace setup in your config eg ours is ‘UQ’.

XSD display mappings are slightly more tricky as they can refer to other xsdmf ids.

This all said, Matt did put some ‘smarts’ into both the xsd import/export and the workflow import/export. As long as you export the XSD display and all the XSD displays it refers to with xsdmf references and xsd display references then the import will be reconnect the references to the new ids created. The same goes for workflows import/export.

We haven’t experienced any problems with the workflow import/export, however we are very careful  with xsd display exports/imports (make sure we get all the referenced displays with the export).

Another simpler option is to make your changes on a staging fez, and simply copy over all the xsd display tables when you make those changes ‘live’. This doesn’t help with upgrading displays however as merging your changes with ours is not simple.

A cleaner way to handle all this would be to not have references between xsd displays at all perhaps.

There are a few options we have discussed, including replacing the XSDMF forms part of fez with an XFORMS (perhaps Orbeon forms) edit/create interface, though this isn’t on the top of our priority list at this point (finishing Solr integration is at the moment fyi).

If we used XFORMS all the templates for edit/create are xml files, which can be merged with a tool like “WinMerge” as they are tex with XPATH text ids (perhaps with namespaces), not db table entries with numeric IDs.

There are existing MODS templates for XFORMS available we could use (eg from Muradora which uses Orbeon XFORMS+MODS templates). The negatives to do this is there is no GUI for editing XFORMS templates currently, however that is probably reasonable OR perhaps altering the current Fez xsd display editor to manager XFORMS templates wouldn’t be too hard.

Cheers,
Christiaan




On 12/03/08 1:02 PM, "Bernadette Houghton" <bernadette.houghton@deakin.edu.au> wrote:

Christiaan, having trawled through the list archives to determine how other people are handling the upgrade of their XSDs, I found a posting from Matt, dated April 2007 (see below).

Matt talks about the possibility of reserving IDs for default templates and thence implementing a mechanism for overriding default settings with custom settings.

As far as I can tell, this hasn't yet been implemented. Is it going to be, or is another mechanism in the pipeline?

We've made extensive customisations to our own XSDs, and the thought of having to re-create these all over again when we upgrade isn't a happy one. I'm also a bit concerned that simply reimporting our existing XSDs into an upgraded installation may break some things.

bern
===================================================
Lynette has raised an interesting issue which I have also been a bit
worried about. The problem is that Fez ships with a bunch of default
Workflows and XSDs that tie in fairly closely to the system.
Administrators at other sites can customise the workflows and XSDs but
it leads to a problem that when they go to upgrade, they will need to
fairly carefully manage their custom workflows. I made it so that Fez
could import and export workflows and XSDs mappings so that the
administrator could choose whether to use their custom stuff or
upgrade to the ones that ship with Fez.

However, it is difficult for administrators to know what's changed and
be able to copy bugs fixes and changes of behaviour into their custom
setups.

Lynette is trying to get around this problem by leaving the default
templates as they are and adding customised templates to override our
default ones.

I'm wondering about making this kind of thing more explicit in Fez so
that we distinguish between the workflows and XSD mappings shipped
with Fez and the customisations. For example we could reserve some
database xsd_id, xdis_ids and wfl_id etc... that are for the default
Fez templates and display a warning that customisations to those
templates will be upgraded when a new version come out. And then have
a mechanism for overriding the default stuff with custom stuff. That
way when they upgrade, the administrator can at least compare the new
workflows and xsds to their customised ones and copy the changes
across.

Any thoughts on that?

MattAt 08:46 AM 11/03/2008, you wrote:
How are other people handling the process of updating their XSDs when upgrading Fez?

Retaining their old XSDs and then making any required changes to the old? Or replacing the old XSDs with the new, and then reapplying any customisations? Is there a third alternative?

TIA

bern

Bernadette Houghton, Access & Data Librarian
Deakin University Geelong Victoria 3217 Australia.
Phone: 03 5227 8230 International: +61 3 5227 8230
Fax: 03 5227 8000 International: +61 3 5227 8000
ICQ: 229654280
Email: bernadette.houghton@deakin.edu.au
Website: http://www.deakin.edu.au <http://www.deakin.edu.au/>
Deakin University CRICOS Provider Code 00113B (Vic)

Important Notice: The contents of this email are intended solely for the named addressee and are confidential; any unauthorised use, reproduction or storage of the contents is expressly prohibited. If you have received this email in error, please delete it and any attachments immediately and advise the sender by return email or telephone.
Deakin University does not warrant that this email and any attachments are error or virus free

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Fez-users mailing list
Fez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fez-users
Bernadette Houghton, Access & Data Librarian
Deakin University Geelong Victoria 3217 Australia.
Phone: 03 5227 8230 International: +61 3 5227 8230
Fax: 03 5227 8000 International: +61 3 5227 8000
ICQ: 229654280
Email: bernadette.houghton@deakin.edu.au
Website: http://www.deakin.edu.au
 <http://www.deakin.edu.au/>
Deakin University CRICOS Provider Code 00113B (Vic)

Important Notice: The contents of this email are intended solely for the named addressee and are confidential; any unauthorised use, reproduction or storage of the contents is expressly prohibited. If you have received this email in error, please delete it and any attachments immediately and advise the sender by return email or telephone.
Deakin University does not warrant that this email and any attachments are error or virus free


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

_______________________________________________
Fez-users mailing list
Fez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fez-users

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Christiaan Kortekaas
Senior Library Open Sorcerer
Library Technology Service
The University of Queensland, Australia QLD 4072
Telephone : (+61) (7) 3346 4337
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~