A generic methodology for the development of railway condition monitoring XML schemas

III INTERNATIONAL CONFERENCE

TRANSPORT SYSTEMS TELEMATIC S TST'03

ZESZYTY NAUKOWE POLITECHNIK] ŚLĄSKIEJ2003

TRANSPORT z .5 1, nr kol. 1608

X M L schema, U M L, co n d itio n m onitoring

Richard LE W IS 1 Clive ROBERTS2

A GENERIC M E TH O DO LO G Y FOR THE DEVELOPMENT OF RAILWAY CONDITION MONITORING XML SCHEMAS

T h is p a p e r in tro d u ce s th e c o n c e p t o f u sing the U n ified M o d ellin g L a n g u a g e (UML) to m o d el a d o m ain fo r e x te n s ib le M ark -u p L an g u ag e (X M L ) sch em as, fo r use w ith in a railway co n d itio n m o n ito rin g a p p lic atio n .

O GÓ LNA METODOLOGIA ROZWOJU STRUKTUR M O NITOROW ANIA STANU KOLEI

A rty k u ł w p ro w a d z a k o n c e p c ję sto so w a n ia Jed n o liteg o Języ k a M odelow ania (U M L ) do m o d e lo w a n ia d o m e n d la sc h e m a tó w ję z y k a e x te n s ib le M ark -u p L an g u ag e (X M L), zn ajd u jąceg o z a sto so w a n ie w a p lik a c ji m o n ito ro w a n ia u w a ru n k o w ań ko lejo w y ch .

1. INTRODUCTION

For m any years rem ote condition m onitoring systems have transm itted data as sim ple text files on a client server basis [1]. The server has a detailed knowledge o f the structure o f the text transm itted and this allows the end user to process the data.

Research has shown that only a small amount o f transducer data is necessary to achieve a level o f m odelling that w ould enable fault detection and allow preliminary diagnosis to be perform ed when raw data is distributed as text based files [2], Initial work using point m achine data, w here raw data was distributed as text, revealed com patibility issues [3], This has led to centralised systems requiring a full version o f the source condition m onitoring software to process and display the data. A requirem ent therefore exists for systems to use common software to process data limits and sharing o f data between disparate systems.

In the UK, w ork has already com m enced in this area in the form o f Network R ail’s Engineers W orkbench (EW B), developed by Atkins Rail who are com mitted to developing a cross platform distributed maintenance system.

1 E lec tro n ic , E lectrical and C o m p u te r E n g in ee rin g , S chool o f E n g in eerin g , T h e U n iv e rsity o f Birm ingham E d g b asto n , B irm in g h a m B 15 2 T T , U K , le w isr@ e e e -fs7 .b h a m .ac .u k

2 E lec tro n ic , E lectrical and C o m p u te r E n g in ee rin g , S ch o o l o f E n g in ee rin g , T h e U n iv e rsity o f B irm ingham E d g b a sto n , B irm in g h a m B 15 2 T T , U K , C .R o b e rts.2 0 @ b h a m .a c .u k

346 Richard LEWIS, Clive ROBERTS W hile the concept o f X M L instance documents and XM L schemas go som e way towards m eeting this requirem ent, some problem s were highlighted by the EWB.

The flexibility o f XM L schemas to model data presents a problem o f constraining param eters and a specific m ethod is required to ensure consistency throughout the model.

A schema can quickly grow to an unm anageable size so a modelling m ethod w ould help to m anage this. M ultiple schem as may help to manage the problem s o f scale, but meta-models are required to then m anage the hierarchy o f multiple schemas used by num erous users.

The user’s ability to produce valid XM L docum ents can be hindered by a lack of understanding o f the schem a provided.

In a previous investigation, the application o f XM L to represent railw ay asset condition m onitoring data was considered [4], In this paper a generic m ethodology for the development o f XML schem as for railw ay condition m onitoring data is described. Particular attention has been paid to a m ethod o f extending conceptual UM L models to constrain the data elements represented as XM L schem a profiles in the model. These profiles describe the com bination of adm inistrative data with raw asset data and the constraint o f the param eters within them.

A logical level diagram is presented that can be used as a basis for com m unicating the m eaning o f the schem a to developers and users. Also presented is a m ethod for defining m ultiple schemas based on a m eta-model for multiple schem a version control.

1.1. D O C U M E N T M O D E L L IN G

Hyper Text Mark-up Language (HTM L) is a language that enables the transfer o f web pages, inclusive o f page display descriptor, over the W orld Wide Web. HTM L however, is limited to a fixed tag set, for displaying the information.

X M L has, in recent years, em erged as an im portant developm ent in the transfer of heterogeneous data on the W orld Wide Web. XML is a m ark up language for documents containing structured inform ation. Structured information consists o f both the content and description o f the role that the data plays [5]. A docum ent model describes docum ents in XML. There are two ways o f m odelling a document:

1) D ocum ent Type Definitions (DTDs);

2) XM L Schemas.

1.1.1. D O C U M E N T T Y P E D E F IN IT IO N S

DTDs have been used extensively in web data m anagem ent and database applications.

DTDs describe a docum ent’s structure with declarative rules and provide inform ation about the content o f docum ents by describing what elements are, and are not, valid.

However, DTDs are lim iting for XM L since they do not provide inform ation on the cardinality o f elements and have a different syntax to the XM L docum ent they describe.

The conversion o f DTDs and other schemas into XML schemas enables the integration and querying o f data [6, 7].

A generic m ethodology for the development o f railway condition m onitoring. 347

1.1.2. X M L S C H E M A

An XM L schem a describes a docum ent’s structure by using element templates. The XML schem a is formed in the same syntax as the XML docum ent it is describing, which is desirable for ease o f understanding. Schemas also allow for elements to be declared as named data types and enable the constraint o f attribute values within elements.

The W 3C consortium has recom m ended a Schema Definition Language that describes and constrains the content o f XM L documents [8]. Industry standard XML Schemas enhance software interoperability by creating flexible file formats. There are a number o f other XM L schem a languages available (Schematron, RELAX NG), though, it is considered that the W 3C ’s will becom e the industry standard. An example o f the use o f the W3C XM L Schema Language is given in this paper.

1.2. G E N E R IC M E T H O D O L O G Y

The generic process for developm ent o f a schema is displayed in F ig .l. The initial step is to apply a Use Case Analysis to the rem ote condition m onitoring system. A Use Case Analysis, form ing part o f the Unified Modelling Language (UML), models the use o f a system, from the perspective o f external systems and users, to define the requirements o f that system. The data elem ents for the domain defined in this process are represented within the schema. If some, or all, o f the assets to be monitored are new or unknown, then the process may include a Failure M ode Effect and Criticality Analysis (FMECA). This activity is based on N etw ork Rail standards for maintenance and user requirem ents for Remote Condition Monitoring (RCM ).

F ig .l. G e n e ric X M L S c h e m a d e v elo p m en t p ro cess

Within the developm ent process is a step to develop a conceptual level UM L model from an analysis o f the domain. The subsequent steps outline the process of analysing the

348 Richard LEWIS, Clive ROBERTS conceptual level diagram in order to create a logical level diagram, from w hich a schema car be created.

A m ethod o f m apping X M L schemas from UML using a database design approach is presented by Routeledge [9]. This m ethod is intended for mapping structured relational data from an existing data system using successive steps. In this m ethod, nesting o f domain elements is established through application o f a rule set in order to achieve minimum redundancy. This m ethod does not lend itself to the application presented here because the data to be m odelled is relatively unstructured and the nesting can, to som e degree, be arbitrarily defined.

Previously, a m ethod o f schem a m apping has been presented that defines schemas designed to support the interfaces o f the functional hierarchical layers o f software component architecture [10].

1.3. C O N C E P T U A L L E V E L D IA G R A M

After the initial analysis is com plete and a list o f the data elem ents essential to maintenance has been created, a conceptual level diagram that contains all o f those elements is defined. At this stage none o f the relationships between elements are indicated, this inform ation will be added in the generic process to follow. This allows focus to be maintained on the elem ents and their content, w ithout the distraction o f their external relationships.

The content o f the UM L classes can now be defined. This need not be comprehensive since the process can be repeated when the domain becomes more fam iliar. The diagram shown in Fig.2 is the result o f this process. It can be seen that the class elem ents have prefixes, w hich indicate to which schem a they belong. These prefixes can be added at any stage in the process, depending on knowledge o f the domain and the application.

A generic m ethodology for the development o f railway condition monitoring...__________349

I »eh M n a 8* ! f... :

L...

J

IB9 A tse lR e g__

sch H a s d s r

C re ale S ubsc np k) n

..I

h a b d P e rio d ic S ia lu s

f

h a b d A larm E venl

^ n i n i e lype * siring l^ p rio rily lype * E v e nlP rionly

h a b d E venlSU a d C o d e lype » h e a d C o d e T IC lype * TOCT ype .jc k D e sc n p lio n lype • siring a m S p e e d lype » sp e e d T y p e - u n i lype ■ a x leC o u n lT ]

^ jle llA la r m B earingT i m p lype * lem pT ype lÜ jn g h iA la rm B e an n g T im p lype » lem pT ype

Fig.2. C o n ce p tu a l Level U M L diag ram

Now that a set o f classes relating to the domain exists, the details of the associations and cardinality can be added to the conceptual diagram. Note that each UML class m aps to a complex type in XM L unless explicitly defined as a user defined type. User defined types are definitions o f U M L extensions, that enable the representation o f simple XML elem ent types, which are difficult to model in UML, such as codes, IP addresses and param eters with specific constraints.

1.4. U M L E X T E N S IO N S

The extensibility m echanism s o f UML are called constraints, tagged values and stereotypes. Extensions are intended to provide additional model characteristics for particular application domains and program m ing environments.

A constraint is a sem antic restriction represented as a text expression, which m ay be interpreted as a num ber o f formal notations such as mathematical notation, psuedocode, program code, etc. If the language used to define the constraint is inform al then its interpretation is also informal and must be done manually.

A tagged value is a pair o f strings that contain some information about an element. This could be inform ation about stereotyped model elements. A stereotype is a type o f model element, defined in the model itself, which is used to tailor the modelling language to a particular application. A stereotype may have a list o f constraints that apply to its usage, and

350 Richard LEW IS, Clive ROBERTS may use tagged values to store additional properties that are not supported by the base element.

The extension m echanism s o f constraints, tagged values and stereotypes make it possible to tailor a U M L profile for the domain under consideration. In this instance the additional m odelling characteristics will be unique to the XM L schema design.

Previously, it has been shown how stereotypes are assigned to one or m ore constructs that are m odified b y the profile extension [11].

In the model presented in this paper a stereotype called anonym ousType is used to represent a restriction on a class that can only exist as an unnam ed com plex type. This stereotype allows only a sequence XM L com positor (model group), which can only contain com position relationships with other elements. The associations with this class will then be num bered with sequenced integer position values. This is shown in Fig.3.

F ig .3 . A n o n y m o u sT y p e in co n ce p tu a l m odel

The com plexType stereotype uses the UpperCamelCase, (i.e. RegisterAssetType as opposed to register A ssetType) elem ent nam ing convention. The XM L com positor type (model group) is indicated in brackets, )}, and the attribute and elem ent m appings are defined as follows:

• Com plex type elem ent instantiations are shown as association end elem ents. These elements will:

o Have position integers represented in brackets and will be an anonym ous type;

o Be false by definition;

o Have nam e m apping o f lowerCamelCase.

UM L content elem ents will also be represented in low erCam elCase nam e mapping.

This is illustrated in Fig.4.

A generic m ethodology for the development o f railway condition monitoring. 351

(modelG roup=sequence)

« c o m p le x ly p e » reg: R eg ste rA sse tT yp e i $ « a t t » id : ty p e = Ulong

! ^ <<al,>> nam e : •VP® = asse tD ataTyp e H « a« t » rar : ty p e = R AR Type

\ ( p o s it b n =.

♦location

« c o m p le x ly p e » reg A s se lT yp e

« c o m p le x T y p e » reg A s s e llo c a lio n T y p e

§ | j j i « a t t » asse tN am e ty p e = asse lN am eT yp e f P « a l l » ve rs io n . ty p e = Ushort

Ü j j « a t t » elr : typ e = ELRType f $ « a t t » miles : ty p e = Ulong

H § « a t t » tra ckID ty p e = tra cklD T yp e

Fig.4. C o m p le x ty p e a sso ciatio n s

Extending a UM L elem ent with the « a t t » stereotype enables the representation o f XML attributes. These can be a user-defined type that restricts a standard XML Schem a Document (XSD) type or standard XSD type. This is shown in Fig.5, where assetName is o f user-defined type AssetNam eType. A user-deftned type inherits the properties o f a sim ple standard XSD type, and then uses a stereotype « X S D f a c e t » to restrict that type.

In Figure 5, the stereotype restricts a string to represent a list o f enum erated types.

« r e s t r i c t s »

\\

\

>3_____

i « x s d : S im pleType>>

: x s d .s trrig

Fig.5. U ser d efin ed type

Extending a U M L elem ent with the « e l t » stereotype enables the representation o f XML sim ple type elements. Again these can be user-defined types extending standard XM L types or ju st standard XM L types.

Another XM L facet, that is non-standard in UML, is the uniqueness constraint. It m ay be a requirem ent for a schem a to represent a parameter that is unique, such as a telephone num ber or, more appropriately, an asset identification number.

352 Richard LEWIS, Clive ROBERTS In previous work an exam ple is presented to illustrate how a uniqueness constraint for a telephone num ber is represented in XM L [12]. This is shown as follows

<xs:unique nam e=”phoneN um s”>

<xs:selector xpath = ”phone”/>

<xs:field xpath=”@ addr:num ber”/>

</xs:unique>

Now if a given contact’s elem ent contains two phone elements with the sam e value for their num ber attribute, the schem a processor will generate an error.

In UM L a sim ple m ethod for representing uniqueness constraints to be m apped to the XM L schem a is required. Previously a m ethod for representing key fields for relational data has been considered [13]. U sing the same principle to represent uniqueness constraints, an symbol is placed in front o f the elements or attribute to be constrained. This is illustrated in Fig.6.

1..*

{position =1}

_ 1 +periodicStatus

(m odelG roupcseq uence}_____________________

« c o m p le x ly p e » h a b d P e rio d icS ta tu sT y pe j | g « e l t » axleC ount : ty p e = axleC ountT ype l8 5 < <e it>> num Trains : ty p e = num TrainsType

^ j « e l t » s y s te m A v a ila b ility : ty p e = s y s A v T y p e l i « a t t » @ recordTim e : ty p e = dateTim e

F ig .6 . U n iq u e n ess c o n stra in t re p re sen ta tio n

1.5. L O G IC A L L E V E L D IA G R A M

Creating a logical level diagram from the original requirem ents, based on the conceptual diagram, involves the use o f standard UM L notations. These are briefly described as follows.

1.5.1. A S S O C IA T IO N

The association relationship type is used to represent relationships between classes within the domain. The instantiation o f the class is indicated by the role nam e given to the association.

1.5.2. IN H E R IT A N C E

This is based on concepts for creating object oriented complex type definitions [14], This allows the subscription class to be abstract such that the class itself shall not be instantiated, only inherited by other classes. This means that subscribe instantiation can become a choice o f create subscription, renew subscription or cancel subscription

A generic m ethodology for the development o f railway condition monitoring. 353

1.5.3. E L E M E N T S A N D A T T R IB U T E S

In general, elem ents and attributes within the conceptual domain can map directly to elements and attributes in the logical level. However, the m ethod described in this paper constrains this flexibility by using stereotypes to force the type definition at the conceptual level.

1.6. L O G IC A L L E V E L D IA G R A M

The diagram in Fig.7 shows the UM L notations and conceptual elem ents described previously, com bined into one logic level diagram for the domain. This diagram shows the representation o f all the elements, param eters and composition inform ation required to create a schema for the railw ay asset condition m onitoring data discussed. This w ould enable the user o f a schema to understand how the elements are related in the schem a layout. Note that the user-defined types are not displayed in this diagram for clarity.

In this diagram it can be seen how information relating to both asset elements, and administrative processes, for rem ote systems are placed in the same schem a docum ent. The nesting o f each data elem ent can be observed from the relationships between them.

“haregr-.

...

tpttkUf ^{{poster =3}

I

V.__

:«arpto<Type» i

.9*1*91 i — , * - 7 = » ^ = - .

:«alt»id tnajedorq -‘■ « * 1 » id LhagtaAxng <-axrrpfexT^pe>>

“ -j...

•> fcrrtD type « IX

|« d t » a : t y p e « U c r g ]

¿ « a t » rare type = ««Oft—

6 « a t> > ra type ■ f*RType "

..

A .1 If ./rrrr*tfiriHFdt*B{

{postoi =1)teXiiK,>

_

¿ « d t » rano type = st/rg

« « d t » pA±t«66 type = iPAilessType

« « d t » period type = irajecffłTTt

^ {rroddGrap=<h»e)

•~4 sgvsHSms ...

¡ ! 5 « d i » ratiD type* Lhsgns

|« a t > > sa y ro c fijT ta type

» « * » cöaQart type = ddelrre I ¿ « a t » cfetćG-d type = ddeTrfe

.t-pao

, 'HMnrt i , .

ta tM ii lrr^O^^.4

«at»»as3etlD type * Itog

« d t » d a c ß t a l type = c&eTrre

« a t » dat& d type * cHeTrre

*seeeKL".l~^B8siife. “Tfltar*

i t » assetNjre type = a ® « d t » et : type * ELRfypeL@tcrr1D type » U tiy B d Irt

« I » w a d i type» Uttot ‘• « a t » tries type» U jrgt.“ .777.7.7... ...7.7.77s -i " « a l t » yads type = Ujtol

• « a t t » iaddD type = ItacMDType

haffiB H i& iiSfyp» ; {nwfcCtcuFssaiB e « d t » afcOx/i type * a*Oxr(

& « 4 t » runTiare typo » rurjTrat,— bsfcoM lS '¿ « d t » sy3<rrAv<iaüty: type? s ‘ < e l » hscCo

^

: :®<*et >> TiadCbSO ptOO type tstm g

<$<•*1» trjr$>eed type ■ p teJype fS <«et»atdC but lype = axJeCiurtTi

v{p3stfcr=<ł

(mxtiGrop=se^jrce)

i g M tin tT •

t « a t » r a r e : type = strrg

> prtnty: type = aertFValyType

> tecodTme type - daeTrre

« - o » --- —--- --- :« < • * • » O c I at typs= S r p

ä > < ^ |» aßeamgTetpL type TenpType

’« < ^ 1 » afleangTorpR t* e = tenpType 7*<*et>> aW tedT»r|l tyye = enpTtpe 7 & « e t» aJAtedTaryP type = fenpfypa t 6 < ^ i» .r ta t f r r tie ' type=idśteTme

♦WeeWan€vertStdis ♦tBargMarrfianSiaus o ' / a -

,... V t .

L tvjrlAlarrCvgtStaiEType ,

• ¿ « d t » vehdelD type = vdrlHDType

! ¿ « a t » adeN rrts type * edeNntoType

» « a t » WtTerp type * tarpType Ö « d t » ncftTmp type» tenpType l» « * t» s c f c .' type = scbType

F ig .7 . L ogical level d iagram

354 Richard LEW IS, Clive ROBERTS

1.7. M U L T IP L E S C H E M A S

In the process o f schem a developm ent and use, a requirem ent m ay exist to issue a new version o f a schem a to represent an amendment to an element, or include an entirely new com ponent schem a to represent a new asset. This proved to be a significant problem to the EWB since num erous parties m ay use a version o f a particular schema. Release o f a new version to one party m ay lead to the re-issue o f a new schema to all users.

In previous w ork, a m ethod is presented that enables a top-level schem a that contains the com ponent schem as in the nam espace [15]. Creating a new release o f that namespace allows the extension o f a set o f com ponent schem a defined in one nam espace. This creates change control since all docum ents valid for a particular release o f a nam espace will also be valid for the next release. Note that in this m ethod, the year o f issue is included in the nam espace nam e to lim it the num ber o f releases, and a prefix is included indicating the origin o f the schema.

A top-level schema, ast_schem a2003_rl .xsd, contains three com ponent schem as, some o f which contain their own com ponent schemas. Extending some o f the com plex elements of ast_RegistrationSchem a_vl to create ast_RegistrationSchem a_v2 creates a requirem ent to re- release the top-level schema. Then ast_RegistrationSchem a_v2 will be included in the new release, but ast_R egistrationSchem a_vl will not.

This is feasible since ast_RegistrationSchem a_v2 still contains all o f the elem ents of ast_R egistrationSchem a_vl, but uses XM L inheritance m echanism s to extend the com ponents requiring am endm ent. This is illustrated in Fig.8.

I ast_sdiema2003 r2 xad — jast xhema2003 rt.xsd '-A

!

F ig .8. E x ten d e d sch e m a v iew

1.8. C O N C L U S IO N

In this paper a generic m ethodology is presented that aids in the developm ent o f models for XM L schemas. Included in this is a brief description o f docum ent modelling.

The exam ple model given is based on railw ay adm inistrative and condition monitoring data and presents the use o f the Unified M odelling Language (UM L) to represent data elem ents and their relationships. A method o f extending standard UM L elements to represent XM L profiles is illustrated.

A m ethod for defining the domain elements in a conceptual diagram is presented and the process o f developing a logical level model diagram is detailed. It is shown how the logical level diagram forms a basis for com m unication o f the schem as m eaning to users.

A generic m ethodology for the development o f railw ay condition monitoring. 355 A concept for the use o f multiple schemas is presented with an example based on a meta-model for m ultiple schem a developm ent from Network Rail Standards.

This work goes some way to addressing the problems experienced by EWB in creating XML schemas. It is shown that UM L provides a solution to the problem o f modelling X M L schema profiles but also highlighted is the arbitrary nature o f the representation o f these elements. The work presented deals with the issue o f setting a standard generic m ethodology for representation o f railw ay condition monitoring data.

A C K N O W L E D G E M E N T

The authors w ould like to thank Network Rail and Atkins Rail for their assistance and continued support during this project.

BIBLIOGRAPHY

[1] D A S S A N A Y A K E , H .P .B , R O B E R T S , C ., G O O D M A N , C .J. (2000). A n architecture for s y ste m -w id e fa u lt d ete ctio n and iso latio n . P ro ce e d in g s o f the IM ech E P art 1 Jo u rn al o f Systems an d C o n tro l in E n g in ee rin g , vol. 2 1 5 , no . 1, p p 3 7 -4 6 .

[2] R O B E R T S , C ., D A S S A N A Y A K E , H .P .B ., L E H R A S A B , N ., G O O D M A N , C .J. (2001). D istrib u te d q u a n tita tiv e and q u a lita tiv e fau lt d ia g n o sis: ra ilw a y ju n c tio n c ase stu d y . 1FAC Control E n g in e e rin g P rac tic e , vol. 10, no. 4 , p p 4 1 9 -4 2 9 .

[3] Z H O U , F., et al. (2 0 0 2 ). R em o te co n d itio n m o n ito rin g and v alid a tio n o f ra ilw a y points. IE E Jo u rn a l o f C o m p u tin g a n d C o n tro l E n g in e e rin g , p p 2 2 1 -2 3 0 .

[4] L E W IS , R ., R O B E R T S , C . (2 0 0 3 ). U sin g X M L to s u p p o rt d istrib u te d maintenance m a n a g e m e n t:

a ra ilw a y in d u stry c a se stu d y . 16* In tern atio n al C o n fe re n ce on C O M A D E M , pp 199-208.

[5] V A N d e r V L 1S T , E. (1 9 9 8 ). W h at is X M L ? w w w .X M L .c o m .

[6] C O L L IN S , S ., N A V A T H E , S ., M A R K , L. (2 0 0 2 ). X M L sch e m a m ap p in g s fo r heterogeneous d a ta b a s e a ccess. In fo rm a tio n an d S o ftw a re T e c h n o lo g y , vol. 4 4 , pp 2 5 1-257.

[7] M E L L O , R ., C O S T A N O , S., H E U S E R , C. (2 0 0 2 ). A m eth o d fo r th e unification of X M L s ch e m a ta . In fo rm a tio n and S o ftw are T e c h n o lo g y , vol. 4 4 , pp 2 4 1 -2 4 9 .

[8] FA L L S1D E , D. (2 0 0 1 ). X M L S c h e m a P art 0: P rim er, h ttp://w w w .w 3.org/T R /xm lscliem a-0/.

[9] R O U T E L E D G E , R ., B IR D , L ., G O O D C H IL D , A . (2 0 0 1 ). U M L and X M L schema, 13* A u stra lasia n D a tab a se C o n fe re n ce .

[ 1 0 ] T H U R S T O N , M . G . (2 0 0 1 ). A n o p e n stan d a rd for w e b -b a se d co n d itio n -b a sed m aintenance s y ste m s, P ro ce e d in g s o f IE E E S y ste m s R ea d in e ss T e c h n o lo g y C o n fe re n ce , p p 4 0 1-415.

[ 1 1 JC A R L S O N D . (2 0 0 1 ). M o d ellin g X M L V o c ab u la ries w ith U M L : P art III. w w w .X N L.com . [1 2 ]H A R O L D , E., M E A N S , W . (2 0 0 2 ). X M L in a nu tsh ell. O ’R eilly & A sso c ia tes, In:.

[13] P R O V O S T , W . (2 0 0 2 ). U M L fo r W 3 C X M L S c h e m a D esign. w w w .X M L .co m . [14] K IM , L. (2 0 0 3 ). T h e o fficial X M L s p y h an d b o o k . W ile y P u b lish in g , Inc.

[1 5 ]D O R E , J., R a iltra c k In fo rm a tio n S y ste m s - X M L stan d a rd s and gu id elin es.

Reviewer: Pro'. Andrzej Lewiński