Tipi di dati del modello composito
Un tipo di dati COMPOSITE è costituito da uno o più valori con gli stessi tipi di dati o diversi. I compositi possono avere una lunghezza fissa o variabile (ma non indefinita). Questo tipo di dati è simile al tipo di dati della struttura C lLanguage.
*DataType: COMPOSITE indirizza un modello a definire un tipo di dati composto i cui membri possono essere di tipi di dati diversi. I membri del tipo di dati COMPOSITE verranno restituiti come singoli elementi figlio XML che appartengono all'elemento che rappresenta il contesto di inclusione. Se ogni elemento figlio rappresenta una primitiva del tipo di dati, il tipo di dati verrà definito dall'attributo XML xsi:type in ogni elemento. Se un attributo GDL è definito come DataType : COMPOSITE, il contesto di inclusione sarà l'elemento <GDL_ATTRIBUTE> . Il nome dell'elemento di ogni elemento figlio XML sarà il tag corrispondente definito da Directive: *ElementTags.
Se composite è un membro di un altro tipo di dati composto, verrà creato un elemento per rappresentare tale contesto di inclusione. Il nome di questo elemento padre sarà il tag corrispondente assegnato dal modello che corrisponde al tipo di dati composto che lo racchiude.
Per definire il tipo di dati COMPOSITE vengono usate le direttive seguenti:
*ElementType (obbligatorio). Nome del modello che definisce i tipi di dati di ognuno degli elementi. È necessario specificare un tipo di dati per ogni elemento. Uno o più elementi possono avere lo stesso tipo di dati. Il numero di ElementType specificati deve essere uguale al valore ArraySize o Max specificato da *ArraySize .
*RequiredDelimiter (obbligatorio). Stringa che separa sintatticamente ogni elemento COMPOSITE dal successivo. Due delimitatori consecutivi verranno interpretati come un elemento omesso. I delimitatori non sono necessari per indicare l'omissione di elementi finali.
È consigliabile prestare molta attenzione se si usano spazi vuoti come delimitatore o come parte della stringa del delimitatore. Ad esempio, il parser interpreterà i caratteri di spazio estraneo come indicanti gli elementi omessi; e perché potrebbero non essere presenti spazi vuoti aggiuntivi, potrebbero verificarsi errori di analisi strani. Inoltre, gli spazi vuoti in eccesso vengono regolarmente rimossi dal file di origine e gli spazi vuoti vengono spesso aggiunti al flusso di input in seguito all'elaborazione di preprocessore, macro e commento. Di conseguenza, la stringa effettiva analizzata potrebbe avere un numero completamente diverso di caratteri di spazio rispetto all'origine specificata. Non è consigliabile usare i caratteri di tabulazioni come parte della stringa del delimitatore necessaria perché vengono convertiti in caratteri di spazio durante l'elaborazione dell'input.
*OptionalDelimiter (facoltativo). Qualsiasi stringa costituita da caratteri specificati in *OptionalDelimiter che appare adiacente alla stringa *RequiredDelimiter verrà considerata parte del delimitatore.
*ElementTags (obbligatorio). Il numero di tag forniti deve essere uguale al valore ArraySize o Max specificato da *ArraySize . Ogni membro verrà contrassegnato con il tag corrispondente. Questo tag è utile se uno o più elementi vengono omessi. Quando gli elementi COMPOSITE vengono omessi, il tag che corrisponde all'elemento omesso non viene utilizzato. Per evitare confusione nel client, non usare i nomi degli elementi riservati dello snapshot GDL come nomi di tag. Questi nomi riservati sono CONSTRUCT, ATTRIBUTE e Personality.
*ArraySize (facoltativo). Se questa direttiva viene omessa, verrà utilizzato un composito a dimensione fissa. La dimensione sarà uguale al numero di nomi di modelli in *ElementType.
Usare due numeri interi per specificare le dimensioni minime e massime consentite per un composito di dimensioni variabili. Si noti che zero è consentito per le dimensioni minime. I tipi di dati COMPOSITE di dimensioni illimitate non sono consentiti. Non è possibile utilizzare il carattere jolly GPD (*) per specificare le dimensioni o le dimensioni massime.
*ArrayLabel (facoltativo). Se questa direttiva viene specificata, l'elenco di elementi COMPOSITE deve essere racchiuso tra parentesi e deve essere preceduto dall'etichetta *ArrayLabel . Se in questa direttiva non viene specificata alcuna etichetta, la parentesi è facoltativa e non è consentita alcuna etichetta di prefazione.
Si consideri il modello seguente.
*Template: QUALNAME_EX
{
*Type: DATATYPE
*DataType: COMPOSITE
*ElementType: (SYMBOL, SYMBOL, INTEGER)
*RequiredDelimiter: "."
*ElementTags: (feature, option, resourceID)
}
Il modello precedente definisce una dimensione fissa, COMPOSITA di due tipi di dati SYMBOL e un numero intero. Composite non etichettato. A ogni elemento in COMPOSITE viene assegnato un ElementTag univoco. Questi tag etichettano ogni elemento nell'output XML per aiutare il client. Ogni elemento è separato dal successivo esattamente da un punto (.); nessun altro carattere viene considerato parte del delimitatore. *ArraySize non è specificato, quindi si presuppone una dimensione composita fissa. Poiché la dimensione COMPOSITE è fissa, non è consentita alcuna omissione dei membri.
*DataType: i modelli COMPOSITI non generano uno schema corrispondente. Viene invece usato lo schema dei modelli denominati nella direttiva *ElementType .
Si consideri ad esempio un modello SYMBOL definito come segue.
*Template: SYMBOL
{
*Type: DATATYPE
*DataType: FILTER_TYPE
*ElementType: XML_STRING
*FilterTypeName: "SYMBOLNAME"
}
Si consideri la voce GDL seguente.
*rcNameID: ( RESDLL.stdname.467 )
In alternativa, prendere in considerazione la voce GDL seguente che non include le parentesi facoltative.
*rcNameID: RESDLL.stdname.467
Si supponga che la voce GDL venga interpretata usando il modello di RC_NAME_ID seguente.
*Template: RC_NAME_ID
{
*Name: "*rcNameID"
*Type: ATTRIBUTE
*ValueType: QUALNAME_EX
*Additive: LEAST_TO_MOST_RECENT
}
L'output XML risultante sarà il seguente.
<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>
Nell'esempio seguente vengono illustrati i tipi di dati composti annidati usando un tipo di dati INTERVAL che contiene una coppia di tipi di dati DATE, che rappresentano un intervallo di tempo. Ogni tipo di dati DATE è composto da un tipo di dati MONTH, DAY e YEAR. Il tipo di dati INTERVAL viene utilizzato dall'attributo VACATION GDL per esprimere un periodo di tempo che un dipendente potrebbe essere assente. La raccolta di modelli seguente consente di eseguire questa situazione.
Modello mese
*Template: MONTHS
{
*Type: DATATYPE
*DataType: ENUMERATOR
*XMLDataType: "months"
*EnumeratorList: (Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec)
}
Modello giorno
*Template: DAY
{
*Inherits: INTEGER
*MinValue: 1
*MaxValue: 31
}
Modello anno
*Template: YEAR
{
*Inherits: INTEGER
*MinValue: 1900
*MaxValue: 2100
}
Modello di data
*Template: DATE
{
*Type: DATATYPE
*DataType: COMPOSITE
*ElementType: (MONTHS, DAY, YEAR)
*RequiredDelimiter: "-"
*ElementTags: (month, day, year)
}
Modello intervallo
*Template: INTERVAL
{
*Type: DATATYPE
*DataType: ARRAY
*ElementType: DATE
*RequiredDelimiter: "to"
*OptionalDelimiter: "<20 09>"
*ElementTags: (start_date, end_date)
*ArraySize: 2
}
Modello di ferie
*Template: VACATION
{
*Name: "*VacationDates"
*Type: ATTRIBUTE
*ValueType: INTERVAL
}
Si consideri la voce GDL seguente.
*VacationDates: Dec-20-2001 to Jan-3-2002
Se questa voce GDL viene interpretata usando il modello VACATION, l'output XML risultante sarà il seguente.
<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>