Tipos de dados de modelo composto

Artigo
06/15/2023

Um tipo de dados COMPOSITE consiste em um ou mais valores que têm os mesmos ou diferentes tipos de dados. As composição podem ter um comprimento fixo ou variável (mas não indefinido). Esse tipo de dados é semelhante ao tipo de dados da estrutura C lLanguage.

*DataType: COMPOSITE direciona um modelo para definir um tipo de dados composto cujos membros podem ser de diferentes tipos de dados. Os membros do tipo de dados COMPOSITE serão gerados como elementos filho XML individuais que pertencem ao elemento que representa o contexto delimitador. Se cada elemento filho representar um tipo de dados primitivo, o tipo de dados será definido pelo atributo XML xsi:type em cada elemento. Se um atributo GDL for definido como DataType : COMPOSITE, o contexto delimitador será o <elemento GDL_ATTRIBUTE> . O nome do elemento de cada elemento filho XML será a marca correspondente definida por Directive: *ElementTags.

Se o COMPOSITE for um membro de outro tipo de dados composto, um elemento será criado para representar esse contexto delimitador. O nome desse elemento pai será a marca correspondente atribuída pelo modelo que corresponde ao tipo de dados composto delimitador.

As seguintes diretivas são usadas para definir o tipo de dados COMPOSITE:

*ElementType (Obrigatório). O nome do modelo que define os tipos de dados de cada um dos elementos. Um tipo de dados deve ser especificado para cada elemento. Um ou mais elementos podem ter o mesmo tipo de dados. O número de ElementTypes fornecidos deve ser igual ao valor ArraySize ou Max especificado por *ArraySize .
*RequiredDelimiter (Obrigatório). Uma cadeia de caracteres que separará sintaticamente cada elemento COMPOSITE do próximo. Dois delimitadores consecutivos serão interpretados como um elemento omitido. Delimitadores não são necessários para indicar a omissão de elementos à direita.

Você deve ter muito cuidado se usar o espaço em branco como delimitador ou como parte da cadeia de caracteres delimitador. Por exemplo, o analisador interpretará caracteres de espaço desnecessários como indicando elementos omitidos; e como talvez você não veja espaço em branco extra, erros estranhos de análise podem ocorrer. Além disso, o excesso de espaço em branco é rotineiramente retirado do arquivo de origem e o espaço em branco geralmente é adicionado ao fluxo de entrada como resultado do processamento de pré-processador, macro e comentário. Portanto, a cadeia de caracteres real analisada pode ter um número completamente diferente de caracteres de espaço do que o especificado originalmente. Você não deve usar caracteres de guia como parte da cadeia de caracteres delimitador necessária porque eles são convertidos rotineiramente em caracteres de espaço durante o processamento de entrada.
*OptionalDelimiter (opcional). Qualquer cadeia de caracteres que consiste em caracteres especificados em *OptionalDelimiter que aparece adjacente à cadeia de caracteres *RequiredDelimiter será considerada parte do delimitador.
*ElementTags (Obrigatório). O número de marcas fornecidas deve ser igual ao valor ArraySize ou Max especificado por *ArraySize . Cada membro será marcado com a marca correspondente. Essa marcação será útil se um ou mais elementos forem omitidos. Quando os elementos COMPOSITE são omitidos, a marca que corresponde ao elemento omitido não é usada. Para evitar confundir o cliente, não use GDL instantâneo nomes de elementos reservados como nomes de marca. Esses nomes reservados são CONSTRUCT, ATTRIBUTE e Personality.
*ArraySize (opcional). Se essa diretiva for omitida, um COMPOSITE de tamanho fixo será assumido. O tamanho será igual ao número de nomes de modelos em *ElementType.

Use dois inteiros para especificar o tamanho mínimo e máximo permitido para um COMPOSITE de tamanho variável. Observe que zero é permitido para o tamanho mínimo. Tipos de dados COMPOSITE de tamanho ilimitado não são permitidos. Você não pode usar o caractere curinga GPD (*) para especificar o tamanho ou o tamanho máximo.
*ArrayLabel (opcional). Se essa diretiva for especificada, a lista de elementos COMPOSITE deverá ser colocada entre parênteses e ser precedida pelo rótulo *ArrayLabel . Se nenhum rótulo for especificado nessa diretiva, os parênteses serão opcionais e nenhum rótulo de pré-fabricado será permitido.

Considere o modelo a seguir.

*Template:  QUALNAME_EX
{
    *Type:  DATATYPE
    *DataType:   COMPOSITE
    *ElementType: (SYMBOL, SYMBOL, INTEGER)
    *RequiredDelimiter: "."
    *ElementTags: (feature, option, resourceID)
}

O modelo anterior define um composite de tamanho fixo de dois tipos de dados SYMBOL e um inteiro. O COMPOSITE não tem rótulo. Cada elemento no COMPOSITE recebe um ElementTag exclusivo. Essas marcas rotularão cada elemento na saída XML para ajudar o cliente. Cada elemento é separado do próximo por exatamente um período (.); nenhum outro caractere é considerado parte do delimitador. *ArraySize não é especificado, portanto, um tamanho COMPOSTO fixo é assumido. Como o tamanho COMPOSTO é fixo, nenhuma omissão de membro é permitida.

*DataType: os modelos COMPOSITE não geram um esquema correspondente. Em vez disso, o esquema dos modelos nomeados na diretiva *ElementType é usado.

Por exemplo, considere um modelo SYMBOL definido da seguinte maneira.

*Template:  SYMBOL
{
    *Type:  DATATYPE
    *DataType:   FILTER_TYPE
    *ElementType:  XML_STRING
    *FilterTypeName: "SYMBOLNAME"
}

E considere a seguinte entrada GDL.

*rcNameID:     ( RESDLL.stdname.467 )

Ou considere a seguinte entrada GDL que não tem os parênteses opcionais.

*rcNameID:     RESDLL.stdname.467

Suponha que a entrada GDL seja interpretada usando o modelo de RC_NAME_ID a seguir.

*Template:  RC_NAME_ID
{
    *Name:  "*rcNameID"
    *Type:  ATTRIBUTE
    *ValueType:  QUALNAME_EX
    *Additive: LEAST_TO_MOST_RECENT
}

A saída XML resultante será a seguinte.

    <GDL_ATTRIBUTE Name="*rcNameID"  >
        <feature  xsi:type="GDLW_string">RESDLL</feature>
        <option  xsi:type="GDLW_string">stdname</option>
        <resourceID  xsi:type="GDLW_int">467</resourceID>
    </GDL_ATTRIBUTE>

O exemplo a seguir mostra tipos de dados compostos aninhados usando um tipo de dados INTERVAL que contém um par de tipos de dados DATE, que representam um intervalo de tempo. Cada tipo de dados DATE é um COMPOSTO de um tipo de dados MONTH, DAY e YEAR. O tipo de dados INTERVAL é usado pelo atributo GDL VACATION para expressar um período de tempo que um funcionário pode estar ausente. A coleção de modelos a seguir realizaria essa situação.

Modelo de Mês

*Template:  MONTHS
{
    *Type:  DATATYPE
    *DataType:   ENUMERATOR
    *XMLDataType: "months"
    *EnumeratorList: (Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec)
}

Modelo de Dia

*Template:  DAY
{
*Inherits: INTEGER
*MinValue: 1
*MaxValue: 31
}

Modelo de Ano

*Template:  YEAR
{
*Inherits: INTEGER
*MinValue: 1900
*MaxValue: 2100
}

Modelo de data

*Template:  DATE
{
    *Type:  DATATYPE
    *DataType:   COMPOSITE
    *ElementType: (MONTHS, DAY, YEAR)
    *RequiredDelimiter: "-"
    *ElementTags: (month, day, year)
}

Modelo de Intervalo

*Template:  INTERVAL
{
    *Type:  DATATYPE
    *DataType:   ARRAY
    *ElementType:  DATE
    *RequiredDelimiter: "to"
    *OptionalDelimiter: "<20 09>"
    *ElementTags: (start_date, end_date)
    *ArraySize: 2
}

Modelo de Férias

*Template:  VACATION
{
    *Name:  "*VacationDates"
    *Type:  ATTRIBUTE
    *ValueType:  INTERVAL
}

Considere a seguinte entrada GDL.

*VacationDates:  Dec-20-2001 to Jan-3-2002

Se essa entrada GDL for interpretada usando o modelo VACATION, a saída XML resultante será a seguinte.

    <GDL_ATTRIBUTE Name="*VacationDates"  >
        <start_date >
            <month  xsi:type="GDLW_months">Dec</month>
            <day  xsi:type="GDLW_int">20</day>
            <year  xsi:type="GDLW_int">2001</year>
        </start_date>
        <end_date >
            <month  xsi:type="GDLW_months">Jan</month>
            <day  xsi:type="GDLW_int">3</day>
            <year  xsi:type="GDLW_int">2002</year>
        </end_date>
    </GDL_ATTRIBUTE>

Partilhar via