Issuing a call for any ACESCentral users who consider themselves proficient in XML and are willing to help cross check this candidate CLF schema for any errors. Your experience and a fresh set of eyes looking at it would be much appreciated. If you spot any issues, you can reply here in this thread, comment directly on Github, or send me an email.
This schema was inherited from the first publication of the spec, and I attempted (crudely) to update it to include the newer process nodes introduced in the CLF 3.0 specification (e.g. Exponent and Log).
Note that the specification should be considered the normative reference, but the schema is intended to be made available as informative resource for those who might like to have it.
(Furthermore, implementers of CLF should be doing more than just validating against this schema and should follow the procedures spelled out in the CLF Implementation Guide.)
I really don’t consider myself very proficient with XML stuff, but I’m familiar with the CLF spec, so I can at least offer a fresh set of eyes. I’ve submitted a PR with a few suggestions.
I’m not really sure how to express that the Info element may contain arbitrary sub-elements (and attributes, I suppose).
Also, it’s occurring to me right now that a LUT1D array may contain either a floatListType or a postiveIntegerListType (i.e., if “rawHalfs” is “true”).
@zachlewis, I appreciate the fresh set of eyes. It seems to me a good idea to add the enumerations you suggest to conform it more to the restrictions specified. Is there any reason in general why one would not want the XSD finely tuned to invalidate non-legal values?
@remia yes, I have previously tested against (most) of them and intend to run against each of those again after with @zachlewis suggested changes in place.
Well, it’s never been quite clear to me how CLF “extensions” are supposed to work – I’m not sure if restricting strings to certain enums in the CLF.xsd would prevent extensions from additional functionality to certain transform types? Could we also specify wildcard string pattern to signify that other values are permitted (but not necessarily implicitly supported)?
I locally resolved a few inconsistent values for xmlns and occasional missing xml declarations on line 1 so that I’d be able to validate each file against the schema.
I have compiled results in a Google sheet. For the legal files, validating is good (green) and no validating is bad (red). For the illegal files, the opposite is true - not validating is good (green) and validating is bad (red).
There are definitely a few situations in the specification which might be difficult or even impossible to enforce with the schema.
Again, if anyone lurking out there is XML savvy and has any suggested enhancements to the schema in order to help reduce the number of red values in the “Validates?” column - your input would be much appreciated in making the schema conform to the specification as closely as possible.