01.07.2013 Views

Ph.D. Thesis - Business Informatics Group

Ph.D. Thesis - Business Informatics Group

Ph.D. Thesis - Business Informatics Group

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

2.3 A DTD to Ecore Transformation Framework<br />

In addition, the EReference is annotated with ≪Validate IDREF(S)≫. Furthermore, the<br />

multiplicity of the EReference is set to the multiplicity of the XMLAttribute.<br />

It has to be emphasized that, since this heuristic is based on name matches, two problematic<br />

cases can occur. On the one hand, it may falsely resolve references in case IDREF(S)<br />

attributes are incidentally named like XMLElemTypes but in fact do not reference them.<br />

On the other hand, it may not be possible to resolve a reference in case IDREF(S) attributes<br />

are not named according to the XMLElemType they shall refer to. Consequently, the user<br />

has to validate if the resolution of the IDREF(S) is correct or if another EClass should be<br />

referenced.<br />

Example. In the running example, the XMLAttribute entity in Figure 2.9(a) is resolved<br />

to an EReference in Figure 2.9(b). In case no name match is found, the IDREF(S)typed<br />

XMLAttribute is transformed into an EAttribute of type EString annotated<br />

with ≪Resolve IDREF(S) manually≫, such as the superEntity EAttribute in Figure 2.9(b).<br />

<br />

<br />

<br />

<br />

(a)<br />

Step 2: Application of Heuristics<br />

relationship<br />

ENTITY<br />

id:EString<br />

name:EString[0..1]<br />

superEntity:EString[0..1] «Resolve IDREF manually»<br />

persistent:EBoolean=“true“«Validate Boolean»<br />

1 entity<br />

0..*<br />

RELATIONSHIP<br />

id:EString<br />

name:EString[0..1]<br />

minCard:EString<br />

maxCard:EString<br />

Figure 2.9: Example of Applying the Heuristics (Step 2)<br />

Heuristic 2 - Boolean Identification<br />

«Validate IDREF»<br />

Heuristic 2 is based on the assumption that an XMLEnumAtt consisting of two XMLEnum-<br />

Literals might represent an attribute of type Boolean (cf. 2.2.3 Limited set of data types).<br />

It recognizes such optimization possibilities and, instead of generating an EEnum, produces<br />

an EAttribute of type EBoolean for the following sets of enumeration literals: {true,<br />

false}, {1, 0}, {on, off}, and {yes, no}. Furthermore, an annotation ≪Validate EBoolean≫ is<br />

added to the attribute. In case the two XMLEnumLiterals are not one of the aforementioned<br />

sets, the produced EEnum is annotated with ≪Resolve possible EBoolean type manually≫,<br />

indicating the possibility of replacing the EEnum by the EBoolean data type.<br />

Example. In the running example, the XMLEnumAtt persistent is identified to be of type<br />

Boolean (cf. Figure 2.9(a)). Thus, in the metamodel, the EAttribute persistent is of type<br />

(b)<br />

31

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!