YAML como superconjunto JSON y caracteres TAB
tabs whitespace (3)
De acuerdo con las pestañas de especificación nunca fueron permitidas. Entonces, cuando JSON se usa dentro de YAML, no permite pestañas.
El problema ocurre cuando pensamos que JSON es un subconjunto puro de YAML. Pero no es, de acuerdo con la sección Relation to JSON en la especificación, hay algunas pequeñas cosas que evitan que json sea un subconjunto puro de YAML.
Si vamos a abordar esas diferencias, lo que necesitaremos es algo así como YSON, que también se menciona en la especificación.
Pero, afortunadamente, hay algunos motores YAML que admiten pestañas como sangrías. Snakeyml es un ejemplo para eso.
No puedo encontrar exactamente una referencia a este error, pero YAML 1.2 dice que es un superconjunto JSON, y si uso tabuladores en un JSON, lo trata como un error.
p.ej
"root": {
"key": "value"
}
(La validación en línea aquí dice que ''/t'' that cannot start any token )
Sé por qué YAML históricamente no permite las pestañas, pero ¿cómo puedo interpretar esto en el contexto de JSON-superconjunto?
(por ejemplo, ¿YAML no es un superconjunto real o JSON también rechaza las pestañas? ¿O la especificación permite pestañas en este caso pero la implementación aún no está allí?)
Gracias.
Sé por qué YAML históricamente no permite las pestañas, pero ¿cómo puedo interpretar esto en el contexto de JSON-superconjunto?
Teniendo en cuenta el resto de las especificaciones, solo podemos concluir que el comentario del "superconjunto" es inexacto. La especificación YAML es fundamentalmente inconsistente en la sección Relación con JSON :
Por lo tanto, YAML puede verse como un superconjunto natural de JSON, que ofrece una legibilidad humana mejorada y un modelo de información más completo. Este también es el caso en la práctica; cada archivo JSON es también un archivo válido de YAML. Esto hace que sea fácil migrar de JSON a YAML si / cuando se requieren las características adicionales.
El RFC4627 de JSON requiere que las teclas de asignación simplemente "DEBERÍAN" ser únicas, mientras que YAML insiste en que "DEBEN" ser. Técnicamente, YAML cumple con la especificación JSON y decide tratar los duplicados como un error. En la práctica, dado que JSON guarda silencio sobre la semántica de dichos duplicados, los únicos archivos JSON portátiles son aquellos con claves únicas, que son, por lo tanto, archivos válidos de YAML.
A pesar de afirmar YAML como un "superconjunto natural de JSON" y afirmando que "cada archivo JSON es también un archivo válido YAML", la especificación inmediatamente nota algunas diferencias con respecto a la singularidad de la clave. Podría decirse que la especificación también debe tener en cuenta las diferencias en torno al uso de pestañas para la sangría aquí también.
Hablando de eso, como lo implica el validador, YAML explícitamente prohíbe las pestañas como caracteres de sangría :
Para mantener la portabilidad, los caracteres de pestañas no deben usarse en sangrías, ya que los diferentes sistemas tratan las pestañas de forma diferente. Tenga en cuenta que la mayoría de los editores modernos pueden configurarse de modo que presionar la tecla de tabulación dé como resultado la inserción de un número adecuado de espacios.
Esto es, por supuesto, más estricto que la especificación JSON , que simplemente dice:
El espacio en blanco se puede insertar entre cualquier par de tokens.
Por lo tanto, para responder directamente a sus preguntas ...
(por ejemplo, ¿YAML no es un superconjunto real o JSON también rechaza las pestañas? ¿O la especificación permite pestañas en este caso pero la implementación aún no está allí?)
... YAML no es en realidad un superconjunto, JSON no deshabilita las pestañas, mientras que la especificación YAML no permite las pestañas explícitamente.
Las pestañas están permitidas en YAML, pero solo donde no se aplica la sangría.
De acuerdo con YAML 1.2 Sección 5.5 :
YAML reconoce dos espacios en blanco : espacio y tabulación .
Los siguientes ejemplos usarán · para denotar espacios y → para denotar pestañas. Todos los ejemplos se pueden validar con el analizador de referencia YAML oficial.
YAML tiene un estilo de bloque y un estilo de flujo. En estilo de bloque, la sangría determina la estructura de un documento. El siguiente documento usa estilo de bloque.
root:
··key: value
En estilo de flujo, los caracteres especiales indican la estructura del documento. El siguiente documento equivalente usa estilo de flujo.
{
→ root: {
→ → key: value
→ }
}
Incluso puede mezclar sangrías en el estilo de flujo.
{
→ root: {
··→ key: value
····}
}
Si está mezclando estilo de bloque y flujo, toda la parte de estilo de flujo debe respetar la sangría de estilo de bloque.
root:
··{
····key: value
··}
Pero aún puede mezclar su sangría dentro de la parte de estilo de flujo.
root:
··{
··→ key: value
··}
Si tiene un único documento de valor, puede rodear el valor con todo tipo de espacios en blanco.
→ ··value··→
El punto es que cada documento JSON analizado como YAML colocará el documento en el estilo de flujo (debido al carácter { o [ carácter [ inicial que admite pestañas, a menos que sea un documento JSON de valor único, en cuyo caso YAML todavía permite el relleno con espacio en blanco.
Si un analizador YAML arroja debido a las pestañas en un documento JSON, entonces no es un analizador válido.
Dicho esto, su ejemplo está fallando porque un valor de mapeo de estilo de bloque siempre debe sangrarse si no está en la misma línea que el nombre de mapeo.
root: {
··key: value
}
root:
··{
····key: value
··}
es válido , y
root: { key: value }
también es válido