Works for me. Thank you!

Should there be a check if there already exists an element with the same ORDER? Or is only the ID the "unique" key and ORDER only an additional information. If I understand the standard correctly all attributes are optional, so it should not matter if there are multiple ORDER-attributes with the same value, right?

Should there be a check if there already exists an element with the same ORDER? Or is only the ID the "unique" key and ORDER only an additional information. If I understand the standard correctly all attributes are optional, so it should not matter if there are multiple ORDER-attributes with the same value, right?

If @ID is provided, it is required to be unique.

As for @ORDER and @ORDERLABEL:

<xsd:attribute name="ORDER" type="xsd:integer" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">ORDER (integer/O): A representation of the element's order among its siblings (e.g., its absolute, numeric sequence). For an example, and clarification of the distinction between ORDER and ORDERLABEL, see the description of the ORDERLABEL attribute. </xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="ORDERLABEL" type="xsd:string" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">ORDERLABEL (string/O): A representation of the element's order among its siblings (e.g., “xii”), or of any non-integer native numbering system. It is presumed that this value will still be machine actionable (e.g., it would support ‘go to page ___’ function), and it should not be used as a replacement/substitute for the LABEL attribute. To understand the differences between ORDER, ORDERLABEL and LABEL, imagine a text with 10 roman numbered pages followed by 10 arabic numbered pages. Page iii would have an ORDER of “3”, an ORDERLABEL of “iii” and a LABEL of “Page iii”, while page 3 would have an ORDER of “13”, an ORDERLABEL of “3” and a LABEL of “Page 3”. </xsd:documentation>
</xsd:annotation>
</xsd:attribute>

(from https://www.loc.gov/standards/mets/mets.xsd)

So, no, I don't think we should enforce unique @ORDER.

But I will check again whether the generic solution here produces valid order values before merging, these should be xsd:integer.

But I will check again whether the generic solution here produces valid order values before merging, these should be xsd:integer.

As long as the user provides an integer, it will be encoded correctly, the mets.xml is valid. If they choose something non-integer-y:

  <error>/home/kba/monorepo/ocrd_all/core/testws/mets.xml: Line 781: Element '{http://www.loc.gov/METS/}div', attribute 'ORDER': 'foo' is not a valid value of the atomic type 'xs:integer'.</error>

I think that is a reasonable assumption that if you have the need to edit the mets:div attributes, you know the allowed value range.

(from https://www.loc.gov/standards/mets/mets.xsd)

So, no, I don't think we should enforce unique @ORDER.

@kba, but IMO we have to respect DFG's application profile for METS here, too. Version 2.3.1 says regarding physical structMap in section 2.2.2.1 (on p.14):

• The ORDER attribute has to contain a numerical sorting value,
  which is used to bring the individual pages into their correct
  physical sequence.
• The ORDERLABEL attribute can contain the pagination of the
  individual page according to the original.
• The LABEL attribute can include the foliation of the individual
  page or the specification of record side and track number.

So regarding the options you presented in #1133,

1. ocrd workspace update-page --order ... --order-label ... --type ... $PAGE_ID which changes/adds the attributes to the mets:div with @ID $PAGE_ID
2. Add these attributes to ocrd workspace add/bulk-add,

I would have preferred option 2 for setting.

See #821 for getting that info on the CLI.