Thanks for this example!
Reading it, I noticed a few details, one of which raised a deeper
question. I begin with the smaller details:
- The namespace declaration (xmlns) is missing on the root element.
- Three closing tags are missing; the placement of two of them (originInfo
and part) may be guessed quite unambiguously.
The placement of the third missing closing tag (relatedItem) is not
straightforward though, because the xsd schema validates both consecutive
and nested relatedItem elements even when one of them has a
@type="constituent" attribute and the other one a @type="host" attribute.
I have used nested relatedItem elements, but never any relatedItem element
with a @type="host" attribute nested within a relatedItem element with a
@type="constituent" attribute. The schema validates such a construct, but
such semantics is unclear. A construct with a relatedItem element with a
@type="constituent" attribute nested within a relatedItem element with a
@type="host" attribute could possibly be considered useful when the order
of the two constituents is unknown, though.
Somewhat similar problems may occur with @type="succeeding" and
@type=preceding"" attribute values.
Therefore, I suggest to write a clarifying note (together with at least
one example) about this topic in the guidelines at
or (if it is considered that some of these constructs should be avoided) I
suggest to modify the schema to avoid them.