Hi there! We have been employing the EPUB parser Type definition in our project and it's been a splendid experience so far! However, we've come across a scenario that piqued our curiosity and hoped to gain some insight into the underlying decisions.
In our use case, we've come across multiple instances where certain elements from the Encryption XML and OPF could potentially be optional. Our expectation was that the type check would indicate this to us, but it appears that these elements are always expected to have a value as per the parser's definition. For instance, it's our understanding that the title, language, and identifier are Required elements in publication metadata, while others could be optional, and similarly, the Keyinfo from the encryption format could be optional as well.
While we do perform our own type checks, there are times when we rely on the parser's type definition as a source of truth, which has led to some discrepancies. Any insights into this would be greatly appreciated. Thank you!
Hi there! We have been employing the EPUB parser Type definition in our project and it's been a splendid experience so far! However, we've come across a scenario that piqued our curiosity and hoped to gain some insight into the underlying decisions.
In our use case, we've come across multiple instances where certain elements from the Encryption XML and OPF could potentially be optional. Our expectation was that the type check would indicate this to us, but it appears that these elements are always expected to have a value as per the parser's definition. For instance, it's our understanding that the title, language, and identifier are Required elements in publication metadata, while others could be optional, and similarly, the Keyinfo from the encryption format could be optional as well.
While we do perform our own type checks, there are times when we rely on the parser's type definition as a source of truth, which has led to some discrepancies. Any insights into this would be greatly appreciated. Thank you!