scscp1.ocd: three examples put placeholder text where an OMATP is expected #44

Summary

Three examples in cd/Official/scscp1.ocd contain the prose placeholder
The header goes here inside an <OMATP>. They are well-formed XML but not
well-formed OpenMath, so they cannot be parsed by a conforming implementation.

This is minor — scscp1.ocd declares <CDStatus>experimental</CDStatus> — and I
raise it only because these files are the natural source of conformance test
vectors, so anyone harvesting them meets these three immediately.

Where

(Line numbers from master at the time of writing; the file has not changed
since 2022.)

The example

<OMOBJ xmlns="http://www.openmath.org/OpenMath">
  <OMATTR>
    <OMATP>
      The header goes here
    </OMATP>
    <OMA>
      <OMS cd="scscp1" name="procedure_terminated"/>
      <OME><OMS cd="scscp1" name="error_memory"/><OMSTR/></OME>
    </OMA>
  </OMATTR>
</OMOBJ>

An OMATP holds a sequence of (key, value) pairs — an OMS followed by an
object — and admits no character data (OpenMath 2.0, §2.1.1). These read as
illustrative sketches in which the SCSCP message header was left as prose, and
nothing in the surrounding text marks them as incomplete.

How I found it

I extracted every <OMOBJ> inside an FMP or Example from the 38 files in
cd/Official/ as conformance vectors for an independent OpenMath 2.0
implementation: 342 objects, of which 339 parse and round-trip cleanly. These
three are the only ones that are not documents.

Possible fixes

Either would do, and the choice depends on what the examples were meant to show:

1. replace the placeholder with a plausible header, e.g. an
   scscp1#call_id / OMSTR pair;
2. drop the OMATTR/OMATP wrapper, so the examples become valid as they stand.

Happy to open a PR for whichever you prefer — I would rather not guess at the
intent.

Disclosure: this report was drafted with AI assistance. The findings are not
generated text — they come from running an independent OpenMath 2.0
implementation locally over a clone of this repository. The line numbers, the
342/339 counts and the <CDStatus> value were produced by that run and re-checked
against the file before posting, so they can be reproduced rather than taken on
trust.