Looking for assistance reviewing CLF XSD

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.)

Heya Scott –

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”).

1 Like

Would it be worth running validation using this candidate schema on the OCIO CLF dataset?

1 Like

@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)?