ldd Repo build process seems to be creating an invalid namespace identifier for the CTLI namespace

[acraugh]

🐛 Describe the bug

The namespace identifier in the latest (1I00) build of the CTLI XSD schema is this (lines 11-12):

targetNamespace="http://pds.nasa.gov/pds4/ctli/v2"
xmlns:ctli="http://pds.nasa.gov/pds4/ctli/v2"

But this is namespace is for use with v1 of the core schema, so the "v2" should be a "v1". The schema files are located in the "v1" tree in the schema directories, as they should be. I do not see anything in the IngestLDD for the CTLI namespace that would result in this error, although I note that CTLI has rolled over to version 2.0.0.0, presumably before this was strongly discouraged/prohibited.

📜 To Reproduce

Not sure what to say about this in this case. Maybe...

1. Go to https://github.com/pds-data-dictionaries/ldd-ctli/blob/main/build/release/1.18.0.0/PDS4_CTLI_1I00_2000.xsd
2. Look at lines 11 and 12.
   The schema was built by the robot, so presumably the result is reproducible by triggering a rebuild...

🕵️ Expected behavior

Until there is a version 2 of the core namespace, all namespaces should only have "v1" in their final segment.

📚 Version of Software Used

No idea. This error is also present in the release 1.16.0.0 version of the file, for the first version with the local 2.0.0.0 version ID.

🩺 Test Data / Additional context

Not really applicable. We noticed it because Oxygen was confused and could not find the schema when the namespace identifier was used to formulate the schemaLocation hint (which should have worked, but didn't).

🏞Screenshots

N/A

🖥 System Info

Not relevant.

🦄 Related requirements

⚙️ Engineering Details

[acraugh]

Additional data: As you would probably expect, this same problem occurs in all XSD files for LDD namespaces that have a major version number of "2" - specifically: ctli, multi, and particle, (I checked while I was updating my schema library.)

[jshughes]

This seems to be a logic bug introduced at the dawn of PDS4. Will check it out and queue a fix.

[jshughes]

Two possible options are to fix LDDTool to not allow a major version number of 2 at this time or have the LDD stewards roll the LDD version number back. I would prefer that we bring others into this decision before proceeding. Maybe @mdrum can bring this issue before the DDWG.

[jordanpadams]

@jshughes @acraugh any verdict on this?

[acraugh]

I reported the problem - I have no authority to fix it or impose a solution; I'm not a steward of any of the affected namespaces; I don't administer the schema tree; and I've already wasted enough breath explaining why I thought allowing dependent namespaces to increment their major versions out of sync with the core would cause problems. Like this one, for example.

I think the DDWG has since decided officially to allow namespaces to increment their major version number as desired for semantic versioning, so directing the stewards to "roll back" - whatever that would mean - is probably not an option. But "allowing" it doesn't actually solve the problem - the canonical schema locations will still be incorrect. So at this point I would suggest that the DDWG and the EN administrator for the schema tree need to sit down together and decide what exactly should happen to namespace URIs and locations when a namespace increments its major version number. That may or may not require a change to LDDTool, depending on what they decide.

They need to decide something sooner rather than later. Right now you have three namespaces that are effectively unusable unless you already know how to hack your schema reference system. The schemas for these namespaces are not located where they are expected - that is, as described in various places in user documentation and training materials. A naïve user who gets a validation error indicating a schema cannot be read has no guidance available to tell them where the "missing" schema might be located. The schema tree is already problematic for cases where a mission namespace is subdivided into instrument namespaces (and the major version increment problem gains an additional layer of complication). Now that the barrier to incrementing the major version number of dependent namespaces has been removed, you've got an increasingly untenable situation for supporting major version increments in namespaces across the board - including with the common namespace.

So the problem still exists, and I can demonstrate it for you, but I can't solve it for you.

[mdrum]

I believe the decision was made with the intent to decouple the major ID of the core IM with that of the namespaces. So, if the namespaces with > 1 major identifier are still being put in some "v1" directory, I think that is what should change.

[acraugh]

That assumes that the /vX/ part of the file location in the schema tree is supposed to represent the major version of the namespace and not the major version of the core IM. There are advantage to decoupling the /vX/ from the namespace version. It only solves the problem for the first level of subdirectories, though, not for the case of subdivided local namespaces.; and it would still require document updates and very clear instructions for users.

[jordanpadams]

@mdrum correct me if I am wrong, but has this been fixed?

[acraugh]

This appears to be fixed, @jordanpadams . Specifically, if I attempt "wget http://pds.nasa.gov/pds4/ctli/v2/PDS4_CTLI_1K00_2000.xsd", I get the expected schema file back, but if I attempt "wget http://pds.nasa.gov/pds4/ctli/v1/PDS4_CTLI_1K00_2000.xsd" (note the /v1/ vs. /v2/), I get a 404 Not Found error, which is also what I would expect. I did not attempt to check other v2 directories - I'm assuming this is automated based on the ldd version.