Add namespaces to exported ISO19139 metadata file.

[wangf1122]

After the fix, the metadata data contains all needed namespaces

[ianwallen]

I believe that by by importing the update-fixed-info.xsl you will be applying all the templates within.
I'm not sure if we want to be applying all those fixes during the export.

i.e. the update-fixed-info.xsl will be applying a gmd:locale for both the main language and the alternate language. This is actually something that we don't want in the export as older geonetwork (i.e. FGP) seem to have issues with them. Does not seem to be an issue with the newer GN.

[ianwallen]

Maybe you can move "add-namespaces" template to src/main/plugin/iso19139.ca.HNAP/convert/functions.xsl
And then you can include src/main/plugin/iso19139.ca.HNAP/convert/functions.xsl from both update-fixed-info.xsl and to19139.xsl.
The "add-namespaces" is also used in iso19139.ca.HNAP.FGP-to-iso19139.ca.HNAP.xsl so it can probably be updated as well.

[wangf1122]

I have moved the add-namespace and its related variables to function.xsl as common template. Then include it to fromISO19139, to19139 and update-fixed-info.xsl. It's still working as import and export and code looks much cleaner.

[ianwallen]

Looks better but you are not using the latest version. Undo your changes from fromISO19139.xsl and apply them to the newer iso19139.ca.HNAP.FGP-to-iso19139.ca.HNAP.xsl and that should resolve your conflicts.

[jodygarnett]

I would like to release 3.10.6 this week is this pull request to be included?

[ianwallen]

@jodygarnett
As there are always changes to the schema - our submodule points to commits rather than releases. So it does not affect us too much if you do a release without this change.
Feel free to do the release as needed. Are you going to switch the version to 3.10.7-SNAPSHOT or 3.10-SNAPSHOT after the release?
That being said - I do believe @wangf1122 will have the remaining issues resolved shortly and this may be committed within a day or 2.

[jodygarnett]

Feel free to do the release as needed. Are you going to switch the version to 3.10.7-SNAPSHOT or 3.10-SNAPSHOT after the release?

I will switch to 3.10-SNAPSHOT if geonetwork/core-geonetwork#5096 goes ahead

[wangf1122]

@jodygarnett
As there are always changes to the schema - our submodule points to commits rather than releases. So it does not affect us too much if you do a release without this change.
Feel free to do the release as needed. Are you going to switch the version to 3.10.7-SNAPSHOT or 3.10-SNAPSHOT after the release?
That being said - I do believe @wangf1122 will have the remaining issues resolved shortly and this may be committed within a day or 2.

Sorry Ian. My email seems stuck yesterday. Didn't see your comment. I am resolving the conflict by merging the main metadata101 3.10 to my folk 3.10. Then my folk 3.10 to this branch. I will review your other comment and do fix accordingly.

[wangf1122]

@ianwallen

I had resolved the conflict. I simply remove the add-namespace declaration and its related variable from "iso19139.ca.HNAP.FGP-to-iso19139.ca.HNAP.xsl" because this xsl already includes the function.xsl. Add-namespace is part of function.xsl.

[ianwallen]

@wangf1122 looks good.
There is one thing that I don't like with the current code.
The functions.xsl now creates some global variables which are also used in update-fixed-info.xsl. This seems to add some confusion in update-fixed-info.xsl as it depends on variables uses elsewhere. It seem like it would be better to keep the global variables in update-fixed-info.xsl and for functions.xsl, the variables should be moved into the add-namespace.
I believe that would make cleaner code.

[wangf1122]

@ianwallen

Hey Ian. I got it fixed as we discussed. I moved these variables to local scope of add-namespace template and move them back to update-fixed-info.xsl as well. Renamed the variables from add-namespace template to make it different from the variables in update-fixed-info.xsl. Now it looks more organized. Please take a look.