“Resources” directory not copying through

[ronaldtse]

From @ejbleys

Is there any reason why the GitHub TC211 Schemas : Resources (https://github.com/ISO-TC211/schemas/tree/master/Resources) directory is not copying through to https://schemas.isotc211.org/Resources?

That directory contains the essence of a whole of TC211 code-lists. This option was discussed at the XMG meeting in June and Mats indicated that, as a technical matter, it should not be but to the vote.

The outcome of the XMG meeting was that it could go forward as a deliverable, acknowledging that other forms of the code-lists would supplement/replace it in the future.

As the file is intended as a list of all codes from all TC211 standards, it does not logically belong within any particular standard (as the base [ISO 19139:2007] has now been withdrawn with no replacement for catalogues)

[ronaldtse]

Not yet working, reopening.

[strogonoff]

@ronaldtse could you point to the code responsible for copying?

[strogonoff]

Makefile?

[ronaldtse]

The files are actually copied in properly but the Jekyll plugin presents it at a different path, therefore it cannot be served at the right path.

[ronaldtse]

Thanks @strogonoff !

[strogonoff]

Is it this one? https://schemas.isotc211.org/schemas/Resources/

So the issue is that it’s supposed to be under a different path?

[strogonoff]

I fail to notice the bug, this aspect of the build appears to be working as designed.

(Note: below, “resource” is used to refer to configuration entry denoting arbitrary resource while “Resources” is used to signify specific directory name.)

• Our library allows multiple resource entries to be specified in configuration.

  Each resource is a directory, in which subdirectories are treated as listings, and contents of those listings are published under /<resource id>/<listing id>/*[/*] (a listing can contain concrete files, as well as further subdirectories with more files).

• Currently, this site is configured to make use only of one resource entry, it’s called “schemas” and included as a submodule.

• The “Resources” directory currently exists as a descendant of “schemas” resource, and is correctly published as such under https://schemas.isotc211.org/schemas/Resources/.

If that is not what’s expected, then I want to clarify the nature of the requirements.

For example, is there an external consumer that expects there to be a top-level /Resources/ path, and cannot be updated to read it from under /schemas/Resources/ instead?

If so, we can approach it in more than one way, with different levels of effort required:

1. We can extend resource configuration to allow any resource to specify select directories to be hoisted up to site root for legacy system support.

   This is a bit fragile and introduces undesirable complexity, for example multiple resource can attempt to hoist the same directory and overwrite each other.

2. The “Resources” directory can be moved out of the “schemas” resource and turned into its own separate resource.

   Then, if it’s important that codelists.xml appears directly under top-level /Resources/ path, we can extend resource publication feature to allow a resource to be itself a listing. This is a relatively smaller change. (Without this change, codelists.xml will have to exist under a listing within the resource, e.g. /Resources/something/codelists.xml.)