Противостоит ли спецификация ads.txt пробелам?

Ты спросил:

if "no field should contain whitespace", why does the specification use spaces in its own examples?

Источник путаницы заключается просто в том, что <FIELD #1>, <FIELD #2>, ... - это не пример, а скорее формат или структура, которым нужно следовать, другими словами, синтаксис. Поскольку синтаксис<FIELD #1> на самом деле является символом, заменой для обозначения позиции. Вы заменяете эту позицию таким значением, как greenadexchange.com

Правило:

No field should contain ... whitespace

Может быть лучше понято как:

no field value should contain ... whitespace

• field здесь используется в смысле содержания в месте или позиции, другими словами field value
• так что это не будет относиться к конкретным символам, которые авторы IAB решили использовать, например, <FIELD #1>.

Тем не менее, авторы IAB, вероятно, могли бы улучшить, написав символы, в которых не использовались пробелы, такие как <FIELD#1> для первого поля, <FIELD#2> для второго и так далее. Это помогло бы избежать потенциального риска путаницы, все еще передавая, что есть первое поле в этой позиции, второе поле в этой позиции и так далее.

Вы также хотели уточнить:

But what about the surrounding spaces? Does the specification by default prefer <FIELD#1>,<FIELD#2>,<FIELD#3>,<FIELD#4> or <FIELD#1>, <FIELD#2>, <FIELD#3>, <FIELD#4>?

Спецификация, похоже, не имеет предпочтения, спецификация только позволяет, что окружающее пространство, потому что она игнорируется.

Рекомендация:

• Ставьте пробел после запятой, чтобы сделать его более понятным и удобочитаемым по сравнению с длинной непрерывной строкой.

Подробные объяснения ниже.

Синтаксис

Если посмотреть на дополнительный текст, окружающий <FIELD..., который вы изначально цитировали, Спецификация IAB ads.txt, страница 7 в формате PDF:

... The records consist of a set of
lines of the form:

<FIELD #1>, <FIELD #2>, <FIELD #3>, <FIELD #4>

or

<VARIABLE>=<VALUE>

В нем написано of the form:, что предполагает, что он собирается представить структуру, другими словами синтаксис, а не пример. Он также не использует слово example на последующих страницах, поэтому этот <FIELD #1>, ... лучше понимать не как буквальный пример, а как иллюстрацию синтаксиса.

Кроме того, когда вы видите что-то в угловых скобках (<, >), например <FIELD #1> и <VARIABLE>, это соглашение, часто используемое в технических руководствах или документации, чтобы означать, что угловые скобки и все, что находится внутри, должно быть заменены по значению, когда вы на самом деле его используете.

Ограничения field, такие как PDF-страница 8: No field should contain tabs, commas or whitespace, лучше понимать как ограничения на значение поля, которое вы в конечном итоге записываете, и не имеют ничего общего с <FIELD #1>, который был просто условием, способом сообщить вам, что здесь есть первое поле. в этом месте или "положении".

Пример 4.1

Позже в разделе: 4. EXAMPLES

Мы можем увидеть, как синтаксис мы видели ранее:

<FIELD #1>, <FIELD #2>, <FIELD #3>, <FIELD #4>

Применяется так:

greenadexchange.com, XF7342, DIRECT, 5jyxf8k54

Мы можем сравнить синтаксис с его реализацией так:

| SYNTAX     | EXAMPLE             | WHAT                             |
| ---        | ---                 | ---                              |
| <FIELD #1> | greenadexchange.com | Domain value                     |
| ,          | ,                   | Delimiter                        |
|            |                     | Ignorable whitespace             |
| <FIELD #2> | XF7342              | Publisher's Account ID value     |
| ,          | ,                   | Delimiter                        |
|            |                     | Ignorable whitespace             |
| <FIELD #3> | DIRECT              | Type of account value            |
| ,          | ,                   | Delimiter                        |
|            |                     | Ignorable whitespace             |
| <FIELD #4> | 5jyxf8k54           | Certification Authority ID value |

• <FIELD #1> синтаксиса заменен на greenadexchange.com, а в greenadexchange.com нет пробелов
• запятая (,) является разделителем, потому что спецификация, PDF-страница 7: a comma separated format, поэтому это разделитель или разделитель
• пробел () будет проигнорирован, потому что обычно все пробелы должны игнорироваться: The consumer systems should ignore any sequence of whitespace or tabs.
• вот почему для вашего значения поля в спецификациях подчеркивается, что у вас не должно быть пробелов, вероятно, потому, что это может запутать вещи, поскольку предполагается, что они игнорируют пробелы

То же самое относится и к остальным в этом примере.

Это правила, но что касается предпочтений, я не смог найти ничего, конкретно предпочитающего пробел или отсутствие пробела после запятой.

Но я настоятельно рекомендую писать запятую, за которой следует space (,), потому что она более четкая и удобочитаемая, чем непрерывная строка текста. Ясность помогает свести к минимуму риск недоразумений и ошибок и, как правило, делает ее более удобной в обслуживании в долгосрочной перспективе.

Дополнительные мысли

По мере чтения дополнительной технической документации вы можете увидеть другие примеры угловой скобки (<...>), которые означают то, что вы заменяете. Один интересный экземпляр находится в Базовые спецификации Open Group, выпуск 7, издание 2018 г.,12. Соглашения о коммунальных предприятиях:

4. Frequently, names of parameters that require substitution by actual values are shown with embedded <underscore> characters. Alternatively, parameters are shown as follows:

<parameter name>

• <FIELD 1>, который привел вас в замешательство, кажется альтернативным методом.

Если бы авторы IAB хотели быть более полезными и избежать риска путаницы, они, вероятно, могли бы написать синтаксис без пробелов.

<FIELD#1>, <FIELD#2>, <FIELD#3>, <FIELD#4>

Или «встроенные символы подчеркивания», как предлагает Open Group Base:

<FIELD_1>, <FIELD_2>, <FIELD_3>, <FIELD_4>

Это, вероятно, было бы более полезным, потому что это еще больше подчеркивает мысль об отсутствии пробелов, а также позволяет избежать возможной путаницы.