Model and Serial numbers

[tschmidtb51]

• fixes Correct default open serial_numbers and model_numbers #847
• correct default open behavior of model and serial number
• introduce escaping
• add conversion rules
• tighten definition: prohibit multiple stars
• add comment that backslashes need to be escaped themselves in JSON strings
• add mandatory test 6.1.43 for stars in model numbers
• add mandatory test 6.1.44 for stars in serial numbers
• add invalid examples
• add valid examples

[sthagen]

@tschmidtb51 please take a look at 8772a18

Note: I was not able to create a branch plus pull request for that, which is OK, but makes me point out this attempt at guessing what we "want" and how "that" should be written here per this comment for clarity.

[sthagen]

LGTM with additional clarifications as suggested or similarly.

Thank you for the amount of work that went into the change set already.
Much appreciated!

[tschmidtb51]

@sthagen Thank you for your feedback.

• The text was very similar across model and serial number
  matching and also exposed (in my reading) "conformance"
  bleeding (e.g. that SHOULD NO be matched is not necessarily a
  concern of the spec).

Thank you. I do still have a concern with one suggested phrase but we can work on that.

• Fixed also some failed CPSR-coding where serial number term
  occurred in the model number description of rules.

Thank you.

• Added an example, where the first part of the model number
  "Pattern" is replaced with an asterisk wildcard

I'll add a few example for the serial number as well.

• Some semantic clarification of phrasing attempted

Thanks.

[tschmidtb51]

Question still remains: Why not allow e.g. -2024-?
I understand from our anchoring requirements (pattern describes
the full string from the set of matching model/serial identifiers)
that we would want to allow shell glob like matching on such texts
from inventory management systems.

Use case in point: In the past model numbers had the year
identifier in the middle. Now in the present there is a problem
with all components from models of the year 2024.
Problem: We force the producer to list all such identifiers
explicitly because we prohibit patterns like -2024-

I thought about that and decide that the advantages do not outweigh the disadvantages. Here are my reasons:

• Matching something like *-2024-* is tricky as this could be anywhere in the string. We want PIH to be unique enough to be a good fit for direct identification of products without a second round of matching - and without a high number of false positives.
• Serial and model numbers are usually finite. So the number of characters they consist of is finite. This also implies, that the lower number of characters could be replaced with ? and the star is used for the other group, e.g. ???????-2024-* or *-2024-???????.
• Serial and model numbers usually have a fixed format. That implies, a case, where *-2024-* is really true, seems seldom. IMHO, it is more likely to have the part of interest at a dedicated point. Such point than can be explicitly stated by using the ? as position indicator.

[tschmidtb51]

@sthagen Here is some new text to improve the partial stuff. Should we remove the term abbreviated from the initial field description?

[sthagen]

SLGTM