v1.3 schema files are requiring changes to validate.

[preston]

This is a technical item that should probably go straight to @cp4cms for follow-up.

Based on a clarifying conversation with @cp4cms and @amsimms last week, I've brought in the "correct" versions of both the 1.3 KAS and composite draft schema into this repository. As is, there are a number of consistent validation errors that I've received on both macOS and Linux, though the actual tools are all based on libxml. I've attached a diff of the changes I've made to do this, which are either case sensitivity mismatches or schema includes. It's pretty frustrating since I believe everything should validate regardless of whether the files referenced by the xsi:schemaLocation lines exist or not.

patch.txt

[preston]

Note that this schema patch resolves all validation issues with the exception of #272 and #274, which are legitimate content authoring errors.

[a-dru-desai]

@kthlnkeating @cp4cms To B3 for review.

[preston]

@a-dru-desai @kbsgitgal This is a notable ticket, as it accomplishes the validation and wellformedness checks on all manifested KNARTs, and composite KNARTs, simultaneously. As of yesterday evening, I have done this on all KNART types delivered thus far. Except for the issues already mentioned, this effectively accomplishes/reproduces steps 2.1 and 2.2 in CDS_KNART_Triplet_Review_Instructions_Final_180525, and as we've seen is catching errors added after the validation reports are generated.

The repository manifest, as of now, includes the full textual summary of any/all errors.

[csp4z]

272 and #274 were both due to post-processing of the KNART XML. @kthlnkeating will be able to supply files against the schema provided in the KNART_Audit repository.

[preston]

@cp4cms Thanks -- this issue though is about needing to patch schema files so they actually work with standalone validation. I think there is some sort of path-related issue in the way the KNART schema locations are written that is masking the issue for y'all, or perhaps it has to do with .xsd dependencies being implicitly loaded by an IDE/Oxygen/whatever by some tool-specific magic that is not present in reviewer environments. Or it could be something I'm doing. Either way, having to change the schema files (CMS) posted to reproduce essentially the same validation seems really wrong.

[csp4z]

There should be no need to change the schema. Schemas are referenced in the KNART.xml with a relative path. Not aware of any tools that don't handle relative paths - it's fairly standard approach in XML. When you and I were on the phone I demoed validation working with 2 different XML editors (Oxygen + XML Mind), same behavior in both. Anyways, let's get the phone again and see if we can figure out together what is happening. Should be quick to figure it all out.

[preston]

Not sure what to do with this issue as I understand what's happening, but from my perspective the relative paths in the schemaLocation are IDE cruft that's useless in downstream consuming contexts and makes observing them impractical.

[csp4z]

Not sure. Requesting feedback from @amsimms

[csp4z]

CDS_Fix was accidentally applied to this earlier. Removing now pending response from @amsimms

[amsimms]

"KnowledgeDocument" is not correct, the published schema states clearly that the root element name is "knowledgeDocument". Chris will follow up on this.

[csp4z]

This was changed post-validation. Any reworked KNART would not have this. @preston: Does this observation that the case was incorrect resolve the problems you were experiencing in try to get these to validate?