Por que o IDS reprova valores que estão corretos?

A expressão regular não perdoa e não explica.

O IDS exige que o código de classificação siga o padrão XX.YY.ZZ. O projetista preenche 12.34.56 e o IDS reprova. O relatório diz: não conforme. Não diz por quê. O projetista tenta 12.34.56. — com ponto no final — e o IDS aprova. O redator do IDS errou o pattern da restriction: escreveu \d{2}\.\d{2}\.\d{2}\. com ponto trailing obrigatório.

No schema do IDS (buildingSMART IDS 1.0), a restriction permite três mecanismos para validar valores: enumeration (lista fechada), pattern (expressão regular XSD) e bounds (limites numéricos). A pattern usa a sintaxe de expressão regular do XSD — não é regex de programação (PCRE), é um subconjunto com regras próprias. Diferenças sutis: XSD regex não tem ^ nem $ implícitos da mesma forma, não tem lookahead, e o comportamento de anchoring varia entre implementações de rule engine.

O redator que escreve pattern sem testar contra exemplos reais produz três tipos de falha: restrição estreita demais (reprova o correto), restrição larga demais (aprova o incorreto) e restrição ambígua (resultado muda conforme o verificador). E o relatório de reprovação não mostra qual parte do valor não casou com qual parte do pattern — só diz "não conforme".

A enumeration também produz defeito: lista incompleta reprova valor válido que não foi enumerado. O redator listou cinco opções de uso de modelo e a equipe adotou uma sexta. O IDS reprova. A equipe conclui que o IDS está errado, em vez de buscar o valor correto na lista.

A §5.6.3 da ABNT NBR ISO 19650-2 exige verificação da garantia da qualidade. Restriction que reprova valor correto ou aprova valor errado não é garantia — é fonte de atrito e falsa segurança.

1. 1

   Reprovação de valor que parece correto · o valor preenchido segue o padrão esperado, mas o IDS reprova. A equipe não entende por quê.

2. 2

   Aprovação de valor fora do padrão · o pattern é largo demais e aceita valores que não deveriam passar — espaços extras, caracteres inválidos, formato diferente.

3. 3

   Resultado diferente entre verificadores · o mesmo valor é aprovado em um rule engine e reprovado em outro. O pattern é ambíguo.

4. 4

   Equipe ignora o IDS · depois de reprovações falsas recorrentes, a equipe para de levar o IDS a sério. O relatório vira ruído.

5. 5

   Relatório sem explicação da falha · o relatório diz "não conforme" mas não mostra em que ponto o valor divergiu do pattern. Impossível corrigir sem ler o XML do IDS.

1. 1

   Pattern escrito sem testar · a expressão regular foi escrita no editor de IDS sem ser testada contra exemplos reais de valores corretos e incorretos.

2. 2

   Regex PCRE em vez de XSD · o redator usou sintaxe de regex de programação (PCRE) em vez da sintaxe XSD do IDS. Metacaracteres com comportamento diferente geram falha silenciosa.

3. 3

   Enumeration incompleta · a lista de valores permitidos não cobre todas as opções válidas. Valor correto que não foi enumerado é reprovado.

4. 4

   Pattern copiado sem adaptar · o pattern veio de outro IDS ou de exemplo na internet sem conferência contra o vocabulário real do projeto.

5. 5

   Sem escape de caractere especial · ponto, parêntese ou barra no valor real não foram escapados no pattern. O ponto casa com qualquer caractere e o pattern aceita o que não deveria.

1. 1

   Retrabalho sobre valor correto · o projetista altera valor que estava certo para satisfazer o pattern errado. A informação piora depois da correção.

2. 2

   Descrédito da verificação automatizada · reprovações falsas recorrentes fazem a equipe tratar o IDS como obstáculo, não como ferramenta. A barreira perde autoridade.

3. 3

   Aprovação de valor incorreto · pattern largo demais aceita formato que não é o padrão. O dado passa pela verificação e chega ao uso com defeito.

4. 4

   Inconsistência entre ferramentas · cada rule engine interpreta o pattern de maneira ligeiramente diferente. O resultado varia conforme a ferramenta, não conforme o dado.

5. 5

   Manutenção impossível · pattern complexo sem documentação vira caixa-preta. Ninguém na equipe sabe o que ele aceita ou rejeita sem testar.

Curto prazo (30 dias):

1. Listar as reprovações falsas. Rodar o IDS atual contra o modelo e separar reprovações onde o valor está correto mas a restriction rejeitou.

2. Corrigir o pattern. Reescrever a expressão regular para aceitar todos os formatos válidos e rejeitar os inválidos. Testar contra lista de exemplos.

3. Completar a enumeration. Adicionar valores válidos que faltam na lista fechada.

Médio prazo (60-90 dias):

4. Criar bateria de teste por restriction. Para cada pattern ou enumeration, manter uma lista de valores de teste (aceitar e rejeitar) que roda automaticamente antes de publicar o IDS.

5. Documentar cada restriction. Registrar, em comentário no XML ou em documento à parte, o que cada pattern aceita e por quê.

6. Testar em dois verificadores. Rodar cada IDS novo em pelo menos dois rule engines antes de colocar em produção.

1. 1

   Pattern testado contra exemplos reais · nenhum pattern entra em produção sem ser testado contra valores válidos e inválidos do projeto. Cinco de cada, no mínimo.

2. 2

   XSD regex, não PCRE · a sintaxe da expressão regular segue o subconjunto XSD. Sem lookahead, sem flags, sem metacaracteres de programação.

3. 3

   Enumeration revisada pelo vocabulário do projeto · a lista de valores é revisada contra o vocabulário real antes de publicar. Valor novo no projeto dispara revisão da enumeration.

4. 4

   Restriction documentada · cada pattern e cada enumeration tem registro do que aceita, do que rejeita e de por que foi escrita assim.

• buildingSMART IDS 1.0Information Delivery Specification. A restriction valida valores por enumeration (lista fechada), pattern (expressão regular XSD) ou bounds (limites numéricos). O pattern usa sintaxe XSD regex, não PCRE — comportamento de metacaracteres pode diferir do esperado por quem programa.
• ISO 16739-1:2024Industry Foundation Classes (IFC4x3). Os valores verificados pela restriction vivem em IfcPropertySingleValue, IfcClassificationReference ou IfcMaterial. O formato do valor no IFC determina o que o pattern precisa aceitar.
• ABNT NBR ISO 19650-2:2022Fase de entrega. §5.6.3 exige verificação da garantia da qualidade antes da troca. Restriction que reprova valor correto não é garantia — é defeito de regra que gera atrito e retrabalho.
• ABNT NBR 15965Sistema de classificação da informação da construção. Quando o IDS valida código de classificação por pattern, a expressão regular deve aceitar todos os formatos válidos da NBR 15965, incluindo separadores e níveis.
• ABNT NBR ISO 19650-1:2022Conceitos e princípios. §6.3.3 institui processos de aprovação documentados e acordados. A restriction é parte do processo — se está errada, o processo de aprovação está comprometido.