La segunda etapa de un enfoque para crear modelos de datos mediante DFDL
implica añadir anotaciones DFDL a la estructura lógica que ha establecido. Las
anotaciones DFDL describen el formato físico de los componentes.
Determine las características de los componentes.
- Todos los elementos (simples y complejos)
- ¿Tiene el elemento delimitadores, es decir, un iniciador o un terminador? Si es
así, ¿qué codificación tienen y están presentes cuando el elemento está vacío o es
nil? Esta característica determina dfdl:initiator, dfdl:terminator y dfdl:encoding,
y las propiedades asociadas.
- ¿Cómo se establece el contenido del elemento? Esta característica determina dfdl:lengthKind y las propiedades asociadas:
- explicit para una longitud fija.
- prefixed si hay un prefijo de longitud.
- delimited si está delimitado por un delimitador.
- pattern para utilizar una expresión regular.
- implicit si la longitud está determinada por su tipo.
- endOfParent, si está limitado por su padre.
- Si el elemento es opcional o una matriz, ¿cómo se establece el número de apariciones? Esta característica determina dfdl:occursCountKind y las propiedades asociadas.
- ¿Hay reglas de alineación aplicables? Esta característica normalmente aparece sólo para datos binarios y determina
dfdl:alignment, dfdl:fillByte y las propiedades asociadas.
- ¿Cómo se describe el valor nulo? Esta característica determina dfdl:nilKind y dfdl:nilValue, y las propiedades
asociadas.
- ¿Se requiere una aserción o un discriminador para establecer si existe el
elemento?
- Elementos simples
- ¿El elemento es una representación de texto o binaria? La representación y el
tipo simple determinan qué otras propiedades se deben establecer.
- Para texto, las propiedades son dfdl:encoding y las distintas propiedades
relacionadas con texto DFDL.
- Para binario, las propiedades son dfdl:byteOrder y las distintas propiedades
relacionadas con binario DFDL.
- Para formatos de texto, ¿se requiere un esquema de escape? Esta característica determina si se requiere una anotación
dfdl:defineEscapeScheme y si por lo tanto un dfdl:escapeSchemaRef debe hacer
referencia a ella.
- Si se identifican tipos simples globales, decida si el tipo simple puede llevar
algunas de las propiedades en lugar del elemento, creando por lo tanto tipos físicos
reutilizables.
- Secuencias
- ¿Es una secuencia ordenada o sin ordenar? Esta característica determina la propiedad dfdl:sequenceKind.
- ¿Tiene un separador que se utilice para delimitar sus elementos hijo? Si es
así, ¿la posición del separador es infix, prefix o
postfix? ¿Los separadores a veces se suprimen (por ejemplo, cuando
faltan elementos opcionales)? Estas características determinan las propiedades dfdl:encoding,
dfdl:separator, dfdl:separatorPosition y dfdl:separatorSuppressionPolicy.
- ¿Tienen todos los elementos hijo de la secuencia iniciadores exclusivos que
puedan identificar que existen? Esta característica determina la propiedad dfdl:initiatedContent.
- ¿Tiene la propia secuencia un iniciador o terminador? Esta característica determina dfdl:initiator, dfdl:terminator y dfdl:encoding,
y las propiedades asociadas.
- Opciones
- ¿En la opción todas las ramas deben tener la misma longitud o no? Esta característica determina dfdl:choiceLengthKind y las propiedades
asociadas.
- ¿Todas las ramas de la opción tienen iniciadores exclusivos que puedan identificar cuál aparece? Esta característica determina la propiedad dfdl:initiatedContent.
- ¿Se requieren discriminadores en las ramas para establecer cuál aparece?
- ¿Tiene la propia opción un iniciador o terminador? Esta característica determina dfdl:initiator, dfdl:terminator y dfdl:encoding,
y las propiedades asociadas.

Para continuar
con el ejemplo de un archivo con registros de empleados, en el que todos los datos
son texto, con dfdl:encoding ASCII.
- El elemento employees no tiene ningún iniciador o terminador,
de forma que dfdl:initiator y dfdl:terminator se establecen en una serie vacía ''.
Su longitud la determinan sus elementos hijo, de forma que dfdl:lengthKind es
implicit.
- La secuencia para employees tiene dfdl:sequenceKind
ordered, puesto que sus componentes hijo siempre aparecen el el
orden especificado.
- El elemento employeeRecords empieza con {, por
lo que tiene dfdl:initiator {{. (Se requieren dos llaves de
apertura ({{) para evitar que el iniciador DFDL se interprete
incorrectamente como una expresión DFDL.) El elemento finaliza con
} y CR/LF, por lo que tiene dfdl:terminator }%CR;%LF;. (Una
alternativa es modelar el } y CR/LF como separador de la secuencia padre.) De nuevo,
su longitud la determinan sus elementos hijo, por lo que dfdl:lengthKind es
implicit.
- Su secuencia tiene dfdl:sequenceKind ordered.
- Cada elemento simple tiene dfdl:representation text. Cada uno
tiene un código de inicio exclusivo que se utiliza como dfdl:initiator. Cada uno
tiene un valor de longitud variable delimitado mediante ',' o, si el elemento es
el último del registro, mediante } y CR/LF. Por lo
tanto, dfdl:lengthKind es delimited.
- El delimitador ',' se modela mejor como dfdl:separator de la
secuencia padre, y no como dfdl:terminator del elemento. dfdl:separatorPosition es
infix lo que significa que la ',' aparece sólo
entre los elementos hijo de la secuencia.
- Dado que cada elemento simple tiene un iniciador, se debe establecer en la
secuencia padre dfdl:initiatedContent yes. Esto significa que el
analizador utiliza el iniciador para identificar positivamente cada elemento.
- Aunque el elemento salary es opcional, no se requiere ningún
discriminador DFDL porque el analizador DFDL deduce que falta cuando encuentra el
terminador employeeRecord. Cuando falta salary,
observe que la ',' delante de él se suprime. Esto se modela
utilizando dfdl:separatorSuppressionPolicy trailingEmpty en la
secuencia padre.
- Para cada elemento simple se deben establecer otras propiedades relacionadas con texto.
Estas propiedades controlan si tiene lugar algún relleno o recorte, y si se
utilizará un esquema de escape para evitar que los caracteres de datos se
interpreten como delimitadores.
- Para cada elemento simple deben establecerse otras propiedades específicas de texto para controlar la interpretación del valor de datos.
Por ejemplo, el elemento permanent es de tipo xs:boolean y por lo
tanto requiere dfdl:textBooleanTrueRep Y y dfdl:textBooleanFalseRep
N.
La siguiente etapa es organizar el modelo DFDL:
Organización del modelo DFDL.