Пройдет ли проверку экземпляр с элементом xsd:token-type, содержащим пробелы?

Конечная цель состоит в том, чтобы предотвратить пробелы в пуле проверенного XML-содержимого, просто не позволяя плохому xs:token содержимому проходить проверку схемы для соответствующих элементов. Экземпляры с недействительной схемой не допускаются в пул.

Если я объявляю тип элемента как xsd:token в XML-схеме (1.1) и пытаюсь проверить экземпляр этой схемы, где элемент с типом xsd:token содержит более нуля отвергнутых символов (табуляция, LF, CR) или двойной , начальный или конечный пробел, будет ли указанный экземпляр проверяться или нет?

Предположим: нет никакого другого «ограничения» (так сказать) на содержание, только то, что оно должно быть xsd:token.

Расширение просто для полной ясности: «Настройка xs:whiteSpace=collapse означает, что начальные и конечные пробелы удаляются, а внутренние пробелы сокращаются до одного символа x20» — я понимаю, что это «предварительная проверка/внутренняя» (поэтому говорить) шаг для валидатора XML; это правильно?


xml validation regex xsd removing-whitespace
person Michael    schedule 17.10.2016    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Ваш вопрос показывает неверное предположение, говоря об «ограничениях» пробелов. Аспект xs:whiteSpace не определяет ограничений, он определяет нормализацию: т.е. что происходит с пробелами перед применением проверки. В большинстве случаев пробелы сворачиваются, что означает, что начальные и конечные пробелы удаляются, а внутренние пробелы сокращаются до одного символа пробела. Если есть грань шаблона, то она применяется к значению после выполнения этой нормализации пробелов.

Обратите внимание, что для xs:token название типа вводит в заблуждение. Экземпляр xs:token может содержать пробелы. Параметр xs:whiteSpace=collapse означает, что начальные и конечные пробелы удаляются, а внутренние пробелы сокращаются до одного символа x20; результатом всегда будет допустимый экземпляр xs:token.

(Конечно, нормализованное значение после проверки представляет интерес только в том случае, если вы обрабатываете информационный набор после проверки, например, с помощью XSLT или XQuery с поддержкой схемы. Если вы выполняете проверку только для получения ошибки, если она недействительна, тогда xs :token и xs:string полностью эквивалентны.)

person Michael Kay    schedule 17.10.2016
comment
Спасибо! Это - если вы выполняете проверку только для получения ошибки, если она недействительна, тогда xs: token и xs: string полностью эквивалентны - это ответ, который я искал! :-) Я отредактировал вопрос благодаря вашему разъяснению: параметр xs:whiteSpace=collapse означает, что начальные и конечные пробелы удаляются, а внутренние пробелы сокращаются до одного символа x20. - person Michael; 19.10.2016
comment
Я должен уточнить утверждение, что xs:token и xs:string полностью эквивалентны. Это неверно, если вы хотите создать тип, производный от ограничения, используя фасет шаблона. Аспект шаблона применяется к значению ПОСЛЕ нормализации пробелов, поэтому один и тот же шаблон будет давать разные эффекты в двух случаях. - person Michael Kay; 19.10.2016
comment
Спасибо, мистер Кей - это очень полезный ответ для других моих вариантов использования. - person Michael; 19.10.2016
comment
Сегодня я снова просматривал спецификацию схемы (как и вы) и заметил часть определения xs:token: › ·лексическое пространство· токена – это набор строк, не содержащих символов возврата каретки (#xD), перевода строки (#xA) и табуляции (#x9), которые не имеют начальных или конечных пробелов (#x20) и не имеют внутренних последовательностей из двух или более пробелов. Не означает ли это, что эти символы недействительны до нормализации (cvc-datatype-valid)? - person mrg; 03.03.2021
comment
Вы упустили тот факт, что лексическое пространство — это не то, что есть в необработанном XML, это то, что вы получаете после применения долексической нормализации, что по сути означает xs:whiteSpace. - person Michael Kay; 03.03.2021
comment
Спасибо. Я не смог найти нигде в схеме, часть 2, где бы это говорилось явно, но это имеет смысл, и спецификация для base64Binary предполагает это: любая строка, совместимая с RFC, может встречаться в элементе или атрибуте, проверенном этим типом, потому что ·whiteSpace · фасет этого типа фиксируется на свертывание, что означает, что все начальные и конечные пробелы будут удалены, а все внутренние пробелы свернуты до одиночных символов пробела до того, как приведенная выше грамматика будет применена w3.org/TR/xmlschema-2/#base64Binary - person mrg; 06.03.2021