Ministerie van Verkeer en Waterstaat
Directoraat-Ceneraa] Rijkswaterstaat Adviesdienst Verkeer en Vervoer
XML Data Definities
Deelonderzoek Marktverkenning Componenten DVMsysteem 28 juni 2002
listerie van Verkeer en Waterstaat 'ectoraat-Generaal Rijkswaterstaat
Adviesdienst Verkeer
Ministerie van verkeer en waterstaat
Directoraat-Generaal Rijkswaterstaat Adviesdienst Verkeer en Vervoer
XML Data Definities
Deelonderzoek Marktverkenning Componenten DVMsysteem 28 juni 2002
Nederlandse Organisatie voor toegepast-natuurwetenschappelijk onderzoek/Netherlands Organisation for Applied Scient;fic Research
TNO TPD Memorandum
TM*
Aan
G.Mol
Afdeling Kennis- en Informatiesystemen Stieltjesweg 1 Postbus 155 2600 AD DELFT www.tno.nl
Van
dr. A. Meyer, ing. D. Regtien, dr.ir. B.D. Netten
XML Data Definities
T 015 269 2000 F 015 269 2111
Onderwerp A W MATCH-AMS XML Datum 28 juni 2002 Onze referentie I&I-MEM-020750
1
Introductie
1.1 Context Bij RWS wordt de Architectuur voor Verkeersbeheersing (AVB) ontwikkeld2. Het in het verleden ontwikkelde arsenaal aan verkeersbeheerssystemen, elk met hun eigen sensoren, actuatoren en regelingen, zal in deze architectuur op een consistente en toekomstgerichte wijze onderling communiceren. De huidige systemen zijn geïsoleerd opgezet en het toevoegen van nieuwe functies is kostbaar en complex. De AVB daarentegen gaat uit van een gecoördineerde inzet van actuatoren en sensoren en biedt een gelaagde netwerkarchitectuur met samenhangende componenten. Voor de verkeersbeheersing staan geautomatiseerde systemen ter beschikking zoals snelwegsignalering, route-informatiepanelen, toeritdoseersystemen, trajectsnelheidssystemen, gladheidmeldsystemen, verkeersmonitoring etc. Er komen regelmatig nieuwe middelen en technieken ter beschikking die ingepast moeten worden in het verkeersbeheerssysteem. De AVB moet daarom enerzijds een raamwerk bieden voor de huidige functionaliteiten en anderzijds een hardware/software infrastructuur bieden voor uitbreiding met nieuwe toepassingen. Binnen de AVB is ook een Informatie Architectuur onderkend1. Hierin wordt een structuur van informatie elementen gegeven voor de dynamische informatie in verkeersbeheersing en management informatie voor het beheer van componenten. Voor verkeerskundige informatie wordt daarin onder andere DATEX (DATa Exchange) als standaard vermeld voor een data dictionary en communicatie protocol. In DATEX wordt de over te dragen informatie ontkoppeld van de onderliggende communicatie mechanismen, en wordt de inhoud en structuur van de informatie afzonderlijk gedefinieerd en gecommuniceerd. Hierdoor is DATEX als informatie standaard open, flexibel, en goed communiceerbaar tussen verschillende verkeerscentrales. DATEX is echter sterk georiënteerd op de beschrijving van verkeerskundige informatie en overdracht tussen gebruikers. Daarnaast bevat de standaard nog veel onnauwkeurigheden en laat ruimte voor interpretatieverschillen. Dit maakt DATEX minder geschikt als standaard voor informatie voor verkeersmanagement en component management.
Contactpersoon B.D. Netten E-mail
[email protected] Doorkiesnummer 015 269 2059 Doorkiesfax 015 269 2111
Nederlandse Organisatie voor toegepast-natuurwetenschappelijk onderzoek ƒ Netherlands Organisation for Applied Scientific Research
TNO TPD
Memorandum
TK# Datum 28 juni 2002
Voor het beheer van informatieverwerkende systemen en componenten wordt in1 een internet gebaseerd network management raamwerk vermeld bestaande uit onder andere het SNMP (Simple Network Management Protocol) met MTB (Management Information Base) als standaard. De MIB is een relatief eenvoudige standaard voor uniforme hiërarchische definitie van componenten en hun parameters. SNMP is een protocol voor communicatie op basis van MTBs. Ook hier is een scheiding tussen inhoud en communicatie doorgevoerd. Dit raamwerk is vooral geschikt voor het beheren van componenten in the applicatie architectuur. Relevante begrippen voor verkeersinformatie en verkeerskundige informatie, zoals verkeerstoestanden, worden derhalve niet gedefinieerd in MIBs voor zover die niet direct als parameters gekoppeld zijn aan applicatie componenten.
1.2 Doel In het MATCH project wordt een verkenning uitgevoerd naar op de markt verkrijgbare producten voor actuator- en sensormanagementsystemen die passen in de AVB architectuur . Een belangrijk aspect bij integratie van producten van verschillende leveranciers is de integriteit van een gemeenschappelijk begrippenkader en gecommuniceerde berichten en data. XML (eXtensible Markup Language) is een taal die in vele domeinen en in toenemende mate wordt toegepast als standaard voor de definitie en representatie van data en berichten. De taal XML is generiek, flexibel, en uitbreidbaar, en niet gekoppeld aan een communicatie protocol. XML lijkt daarom geschikt voor definitie van een begrippenkader, data en berichten voor communicatie van verkeers-, verkeerskundige, en verkeersmanagement informatie. Het doel van dit document is om inzicht te geven in de toepasbaarheid en meerwaarde van XML als taal voor de specificatie van data definities en berichten in AVB. De vraagstelling in dit document is niet zozeer om een vergelijking te maken van XML met DATEX en MIBs. Een beperkte vergelijking met MTBs zal echter gemaakt worden als referentie kader vanwege de bekendheid met SNMP en MIBs bij A W .
1.3 Doelgroep Dit document dient om het MATCH rapport3 aan te vullen en te onderbouwen t.a.v. technische aspecten die relevant zijn voor het gebruik van XML als specificatie taal voor data en bericht definities. Dit document is in eerste instantie bedoeld als achtergrond informatie voor de opdrachtgever en daarnaast ook voor de doelgroep van het MATCH rapport zelf. In sectie 4.2.8 van dit MATCH rapport is een excerpt opgenomen van de beschouwingen die in dit document zijn weergegeven, dat tevens als samenvatting van dit memorandum kan worden beschouwd.
1.4 Leeswijzer Allereerst wordt de context geschetst waarbinnen berichten en data gecommuniceerd moeten worden tussen componenten. Deze context identificeert de noodzaak voor goede en eenduidige definities van het begrippenkader, berichten en data elementen, teneinde verschillen in interpretatie tussen componenten te voorkomen of beperken.
Onze referentie I&I-MEM-020750 Blad 2
Nederlandse Organisatie voor toegepast-natuurwetenschappelijk onderzoek / Netherlands Organisation for Applied Scientific Research
TNO TPD Memorandum
TH*
In hoofdstuk 3 wordt een MIB besproken van een dynamic message sign (DMS) die is ontwikkeld door A W en dient als voorbeeld van een data definitie en referentiekader in daarop volgende hoofdstukken. Vervolgens wordt de markup taal XML uitgelegd en uitgewerkt voor het voorbeeld van de DMS. Ten slotte worden enkele gereedschappen, of tools, gepresenteerd waarmee een begrippenkader en data definities gespecificeerd kunnen worden in XML.
2
Communicatie tussen componenten
De context voor definitie van data en berichten is een proces waarin data middels berichten wordt uitgewisseld tussen componenten van potentieel verschillende leveranciers. Dit proces kan op drie niveau's worden beschouwd: 1. Transport van een individueel bericht. 2. Interactie van componenten door uitwisseling van berichten. 3. Het begrippenkader waarbinnen componenten interacteren. Dit hoofdstuk schetst de context waarbinnen data en berichten worden gecommuniceerd tussen autonome software componenten, ook wel software agents genoemd. We hanteren hier de architectuur en conventies van FIPA (Foundation for Intelligent Physical Agents). Dit is een onafhankelijke en internationale organisatie voor de ontwikkeling van open standaarden en specificaties voor interoperability tussen agentgebaseerde systemen en hun toepassing in de industrie. Hierbij is een sterke relatie met de OMG 5 (Object Management Group), onder andere op het gebied van interoperability en CORBA, waarbij FIPA zich specialiseert in software agents als autonome, en eventueel intelligente en mobiele, componenten. FTPA specificeert een abstracte architectuur voor software componenten. Hierin worden onder andere onderkend; een model voor de services, interoperabiliteit van berichten transport, scheiding van transport, communicatie en inhoud van berichten, talen voor communicatie en inhoud van berichten, en standaard protocollen voor interactie tussen componenten.
2.1 Transport In zijn meest eenvoudige vorm kan communicatie worden beschouwd als het transporteren van een bericht van een verzender naar een ontvanger. Figuur 1 toont de basiselementen van een bericht voor transport volgens de FIPA specificatie 6. Voorlopig wordt aangenomen dat de inhoud van een bericht bekend is, en klaar is voor verzending, en dat de naam van de ontvanger bekend is bij de verzender. De eerste stap is dat het bericht met identificatie van verzender en ontvanger verpakt moet worden in een zogenaamde envelope. Hierbij wordt het bericht, of envelope, gerepresenteerd in een gedefinieerde taal. FIPA specificeert hiervoor de Agent Communication Language, of ACL. Deze taal moet bekend zijn bij alle componenten om de inhoud van een bericht te kunnen verzenden en ontvangen via het transport mechanisme '.
' Dit impliceert nog niet dat de componenten de inhoud van een bericht ook kunnen begrijpen, correct interpreteren en verwerken.
Datum 28 juni 2002 Onze referentie I&I-MEM-020750 Blad 3
Nederlandse Organisatie voor toegepast-natuurwetenschappeli-k onderzoek / Netherlands Organisation for Applied Scientific Research
TNO TPD
Memorandum
De tweede stap is dat de namen van verzender en ontvanger door het transport mechanisme worden vertaald naar adressen in het netwerk via een naming service. Ook moet het bericht worden gecodeerd in het formaat waarin het via het netwerk getransporteerd kan worden. Een tekstbericht kan bijvoorbeeld vertaald worden naar een binair formaat voor efficiënter transport. Belangrijke concrete realisaties van bovengeschetste communicatie- en transport mechanismen zijn Remote Procedure Calls (RPC), SOAP en CORBA (zie bijlage C). • Bij Remote Procedure Calls (RPC) worden alleen de data elementen als argumenten doorgestuurd. Bij CORBA wordt dit gedefinieerd in een Interface Definition Language (IDL). Daarbij is geen taal (content-language) nodig om de inhoud van het bericht te formuleren. • SOAP7 is een protocol gebaseerd op XML/HTTP. Het beschrijft wat er in een bericht staat, hoe berichten afgehandeld moeten worden en conventies voor het representeren van RPC-aanroepen en RPC-responses. Communicatie door middel van SOAP in combinatie met XML kan een alternatief zijn voor CORBA. • Software agents kunnen wel een bericht opstellen in een gedefinieerde taal, zoals SL4, CCL, KIF, of XML RDF.
;
Addrsss hgand rrore allribules
f.tessage-erc odin:
Monnqrjo < ' < << Sender: ..agent nanre Recsiver{s>: sgentname{s)
Massage content
V
Serrier agent name Rêcek'örisi: agentes}
Message content
Figuur 1: Structuur van berichten voor transport (bron 6)
2.2 Interactie FIPA beschouwt communicatie als een interactie tussen software componenten. Een dialoog is een voorbeeld van een interactie tussen twee componenten, waarin één component is te beschouwen als initiator tot de dialoog, en de andere component als responder. Een dialoog is niet slechts een enkele communicatie stap, waarin een bericht wordt verzonden door een initiator en ontvangen door een responder. Een dialoog is een complex proces waarop componenten met elkaar interacteren en waarin informatie in een reeks volgordelijke berichten wordt uitgewisseld.
Datum 28 juni 2002 Onze referentie I&I-MEM-020750 Blad 4
Nederlandse Organisatie voor toegepast-natuurwetenschappelijk onderzoek/Netherlands Organisation for Applied Scientific Research
TNO TPD Memorandum
T«#
Dit kan inzichtelijk worden gemaakt in een sequentiediagram zoals Figuur 1 uit de specificatie van het FIPA contract net protocol6 voor het aangaan van een overeenkomst om informatie te leveren. Een pijl geeft een bericht aan dat verstuurd wordt. De initiator verstuurt bijvoorbeeld een open vraag voor levering (call-for-proposal, of cfp), en verwacht daarop een voorstel (proposal) terug te ontvangen die de initiator vervolgens kan accepteren of afwijzen.
FIPA -Co ntractNet- Protocol Participant
Initiator
cfp (agtbn, preconditjon)
ref use (reason-1)
0
D
IdeadA . line
not-undarstood
propose (piecondrtton-2)
reject-proposal (reason-2)
H
accept-proposal (proposal) inform
«e
fr
tailure (reason-3)
Figuur 2: Sequentiediagram van het FIPA Contract Net Protocol (bron ) Iedere pijl is een afzonderlijke communicatie handeling, waarin een bericht wordt verstuurd volgens een afgesproken communicatie protocol zoals beschreven in sectie 2.1. De inhoud van het bericht is tussen haken aangegeven, bijvoorbeeld de voorwaarde waaronder een voorstel wordt gedaan: propose(precondition). De keuze momenten in een conversatie zijn eveneens gedefinieerd in het diagram middels een ruit op een dikke verticale lijn. Figuur 2 laat zien dat bepaalde typen berichten, zoals een precondition en een reason, om meerdere redenen en op verschillende momenten kunnen worden gecommuniceerd.
Datum 28 juni 2002 Onze referentie I&I-MEM-020750 Blad 5
TNO TPD
Nederlandse Organisatie voor toegepast-natuurwetenschappelijk onderzoek / Netherlands Organisation for Applied Scientific Research
Memorandum
De betekenis en intentie van een bericht verschilt daarbij sterk. Belangrijk hierbij is dat ieder bericht in een interactie een communicatieve handeling is met een specifiek doel, waarbij de gesprekspartners een duidelijk verwachtingspatroon hebben omtrent de inhoud van het bericht, de fase in de dialoog, de mogelijke typen reacties, en het verdere verloop van de dialoog. • Het type van de communicatieve handeling, of"'communicative act", moet expliciet vermeld worden in het bericht zelf zodat de intentie van het bericht duidelijk gecommuniceerd wordt. De communicative act is aangegeven als kwalificatie van een pijl in het sequence diagram (Figuur 2). • De inhoud van het bericht is tussen haken aangegeven, bijvoorbeeld de voorwaarde waaronder een voorstel wordt gedaan: propose(precondition). FIPA definieert 22 standaard communicative acts, zoals de call-for-proposal (cfp), een vraag naar informatie (query), verzoek tot het verrichten van een actie (request), een mededeling (inform), subscribe, en enkele typen foutmeldingen zoals een not understood oifailure. Het standaard patroon van communicatieve handelingen, zoals wordt vastgelegd in een sequentie diagram, heet een interactie protocol11. FIPA heeft een aantal standaard interactie protocollen gespecificeerd, zoals het contract net, een vraag om informatie te ontvangen (query), een verzoek om een handeling te verrichten (request), en enkele onderhandelingsmodellen. Zelfs het meest eenvoudige interactie protocol, de query (Figuur 3) vereist twee berichten; de initiator die de communicatieve handeling voor de vraag (query communicative act) verstuurt, en de responder die de communicatieve handeling verricht voor het mededelen van het antwoord (inform). Op een hoger niveau van de applicatie architectuur moet de interactie tussen componenten worden ontwikkeld. Toegepast op een AVB architectuur legt een interactieprotocol bijvoorbeeld vast: • Welke berichten een component kan versturen naar een ander component. • Welke berichten ontvangen kunnen worden door een component. • Hoe te reageren op uitzonderingen of voorziene afwijkingen (bijvoorbeeld 'not understood'). Deze sectie identificeert dat van een bericht niet alleen de inhoud gedefinieerd moet worden, maar dat ook het interactie protocol en de communicatieve handeling binnen dit protocol duidelijk gedefinieerd moet worden om de inhoud van het bericht juist te kunnen interpreteren en daar op de juiste wijze op te kunnen reageren.
Niet te verwarren met een communicatie protocol waarin wordt vastgelegd hoe een bericht wordt ingepakt (envelope) en getransporteerd (zie sectie 2.1).
Datum 28 juni 2002 Onze referentie I&I-MEM-020750 Blad 6
Nederlandse Organisatie voor toegepast-natuurwetenschappelijk onderzoek / Nerherlands Organisation for Applied Scientific Research
TNO TPD Memorandum
TH* Datum 28 juni 2002 Initiator, Participant query-if. query- ref, ref use*. not-undenstood*. failure*. inform*
Fl PA-Query-P rottco I
Participant
I nitiator query-if
-£|
query-ref
not-understood
u
refuse
I
I
failure
ff
inforrn
Figuur 3: FIPA Query interaction protocol (bron ).
2.3 Begrippenkader voor berichten In deze sectie wordt aangenomen dat een bericht getransporteerd kan worden, zodat een bericht goed verpakt, verzonden, ontvangen, en uitgepakt kan worden. Ook wordt aangenomen dat het interactie protocol en de communicatieve handeling van een bericht gekend zijn, zodat de intentie van het bericht en mogelijke reacties in de interactie met de gesprekspartner gekend zijn. De component beschikt nu over de kale inhoud van het bericht, maar dat impliceert echter nog niet dat de inhoud van het bericht gelezen en begrepen kan worden. In een complex systeem met componenten van verschillende leveranciers worden veelal meerdere talen, begrippenkaders, interactie en communicatie protocollen gehanteerd. Daarom moeten ook de taal (content language) waarin een bericht geschreven is, en het begrippenkader dat wordt gehanteerd, moeten expliciet worden vermeld in het bericht en gekend zijn bij de componenten. Figuur 4 geeft een overzicht van de belangrijkste elementen van een bericht. • Het bericht moet goed ontleed kunnen worden om de termen (namen van individuele entiteiten) of parameter waarden juist te kunnen identificeren en lezen. De inhoud van een bericht kan een lijst van argumenten zijn, zoals in RPC. De inhoud kan echter ook geformuleerd zijn in een taal (content language) met proposities, acties en
Onze referentie I&I-MEM-020750 Blad 7
Nederlandse Organisatie voor toegepast-natuurwetenschappelijk onderzoek / Netherlands Organisation for Applied Scientific Research
TNOTPD Memorandum
termen. Een concrete instantiatie van een content language is bijvoorbeeld XML RDF (zie paragraaf 4.1). Daarna moeten de onderscheiden termen en parameter waarde nog juist geïnterpreteerd worden. Dat wil zeggen dat de betekenis van de termen of parameters gekend moet zijn. De betekenis wordt gedefinieerd in een zogenaamde ontologie.
Expressed in an Agent-com munication-bnguage
Unque na mes. regaidless of transport.
Sender: Agent-name Receiver(s): Agent- mme(s} M es sag e conte nt Expressecl in a content-laoguage May ref ere re e one or more orrtofogy
Figuur 4 Elementen van een bericht Een ontologie is een verzameling van definities van begrippen en concepten in een applicatie domein. Daarbij worden begrippen, concepten, modellen, attributen, acties en predikaten gedefinieerd, aan elkaar gerelateerd en met kwalitatieve of kwantitatieve beperkingen voorzien. Een ontologie specificeert dus het vocabulaire van een domein waarmee over de entiteiten uit dit domein gecommuniceerd kan worden (syntax) en de betekenis van entiteiten (semantiek) door de relaties en beperkingen aan te geven. Een ontologie definieert meer dan een taxonomy (een hiërarchische classificatie structuur van componenten en hun attributen) of een data definitie van termen alleen. Een ontologie wordt altijd gedefinieerd vanuit een bepaalde toepassing (zoals een dynamisch bord), taak en doelstelling. Een ontologie definieert dus geen objectief maar een subjectief begrippenkader. Door verschillen in gezichtspunten tussen disciplines, leveranciers, projecten en producten, verschillen ook de begrippenkaders die worden gehanteerd. Deze subjectiviteiten kan tot communicatieproblemen leiden indien de verschillen niet worden onderkend en opgelost. Het voordeel van het hanteren van een ontologie is dat de subjectiviteit expliciet zichtbaar gemaakt wordt middels de kwalificaties van concepten en definities van de relaties daartussen. Hierdoor kan de subjectiviteit wel worden onderkend worden, en kunnen transformaties worden gedefinieerd tussen termen uit verschillende ontologiën. Voor bepaalde toepassingen kan van meerdere ontologieën tegelijk gebruik gemaakt worden. Zo kan een ontologie voor een specifieke actuator worden geïntegreerd in een
Datum 28 juni 2002 Onze referentie I&I-MEM-020750 Blad
Nederlandse Organisatie voor toegepast-natuurwetenschappelijk onderzoek ƒ Netherlands Organisation for Applied Scientific Research
TNO TPD Memorandum
TM*
generieke ontologie voor een verkeersmaatregelen. In dat geval moeten de ontologieën geïntegreerd worden en moeten geen tegenstrijdigheden bevatten. In deze sectie is onderscheid gemaakt tussen de betekenis van termen en hun gebruik in een taal. Hierdoor kan de definitie van termen in een ontologie worden gescheiden van het opstellen van berichten. Met andere woorden, de betekenis van verkeerskundige begrippen en parameters kunnen nu eenduidig worden opgesteld, onafhankelijk van de interpretatie in de communicatie tussen componenten. De termen kunnen vervolgens op verschillende wijzen worden gebruikt in berichten door gebruik te maken van de expressiviteit van de taal.
2.4 Definities voor communicatie In de introductie is reeds onderscheid gemaakt tussen het transport mechanisme om berichten te versturen en de informatie in de berichten. In dit hoofdstuk is het belang aangegeven om de "informatie" in een bericht verder te onderscheiden in: • Inhoud van een bericht, met: o Ontologie: de betekenis van termen in een bericht. o Content-language: de taal waarin een bericht wordt opgesteld, of te wel de structuur waarin de termen (data) wordt gerepresenteerd. • Communicatieve handeling: de intentie waarom het bericht is verstuurd • Interactie protocol: afgesproken protocol om te interacteren. Bij het versturen van berichten mogen berichten uitsluitend de begrippen van de ontologie bevatten en moeten de syntax (inclusief structuur) van de afgesproken taal volgen. Bij het ontvangen van een bericht gebruikt de ontvanger de ontologie en taal om het bericht te ontsluiten en de betekenis van de daarin zich bevindende informatie te interpreteren. Scheiding van ontologie en taal is belangrijk voor interoperabiliteit. Een ontologie is domein specifiek, en veelal zelfs component specifiek (bijvoorbeeld een dynamisch bord van leverancier X en type Y). Een ontologie kan dus niet veranderen in de communicatie tussen twee componenten (van bijvoorbeeld verschillende leveranciers of product familie). De taal waarin een component communiceert kan echter wel veranderen en worden afgestemd met ander componenten. Een interactie protocol definieert de verantwoordelijkheden en keuze mogelijkheden voor interactie tussen componenten. Uit de sequentie van communicatieve handelingen kan worden afgeleid in welke toestand van het protocol een component zich bevindt, hoe de component moet reageren (welke actie), en hoe de interactie verder zal kunnen verlopen. Bij RPC-achtige communicatie zijn taal, ontologie, en interactie protocol volledig met elkaar verweven. Bij gevolg moet ieder bericht apart worden gedefinieerd als procedure call, waarbij impliciet een betekenis wordt gegeven aan de combinatie van parameters, de communicatieve handeling, en de fase in een interactie.
Datum 28 juni 2002 Onze referentie I&I-MEM-020750 Blad 9
TNO TPD
Nederlandse Organisatie voor toegepast-natuurwetenschappelijk onderzoek / Netherlands Organisation for Applied Scientific Research
Memorandum
3
Management Information Base (MIB)
SNMP (Simple Network Management Protocol) 9 is een communicatie mechanisme dat wordt toegepast in verkeersmanagement 3 . In SNMP communiceren twee componenten, of managed objects in SNMP terminologie, door waarden in data stromen uit te wisselen via een get/set mechanisme op een database. SNMP kan worden beschouwd als een database management benadering voor communicatie. De structuur van de data in de database wordt gedefinieerd als een MTJB (Management Information Base). In een MIB worden objecten, of componenten, beschreven in hun onderlinge hiërarchie en met hun attributen (parameters). De ontwikkeling van een communicatie proces via SNMP en MIBs onderscheidt 3 stappen: 1. Specificatie van data definities in een MIB 2. Generatie van programmatuur voor het genereren en interpreteren (encoding and decoding) van data stromen tussen componenten. 3. Netwerk communicatie protocol voor het verzenden, transporteren, en ontvangen van informatie, zijnde SNMP. Een MIB wordt gespecificeerd in de standaard taal ASN.1 (Abstract Syntax Notation). Deze taal ondersteunt de definitie van parameters van standaard data typen met hun validiteitsdomein en objecten als structuren van een verzameling parameters. Daarnaast kunnen ook macro's of scripts, en modules voor de organisatie van scripts, worden gedefinieerd. Een MTJB is een data definitie met een hiërarchische structuur. De MIB bevat een collectie van veldnamen met bijbehorende waarden en ongelabelde relaties (entity relations). De MIB bevat echter niets over de betekenis van de beschreven objecten, bijvoorbeeld in de vorm van onderlinge semantische relaties ter kwalificatie van objecten of concepten. De component die de data in de MTJB van het betreffende apparaat beheert, wordt een agentm genoemd. Een andere component kan communiceren met het apparaat middels get/set opdrachten naar de agent. Componenten moeten de data stromen kunnen genereren en interpreteren volgens de specificatie, en deze communiceren via een MIB. Standaard tools zijn beschikbaar om uit de specificatie de MIB database structuur te genereren en ook de software modulen voor het genereren en interpreteren van de get en set opdrachten. Deze modulen moeten vervolgens geïntegreerd worden in de componenten van het DVM systeem die met elkaar moeten communiceren. Veelal wordt een MIB gedefinieerd voor een specifiek apparaat (device) zoals een Dynamic Message Signs (DMS). Naast de component voor de DMS zelf, moeten alle componenten die met de DMS agent willen communiceren de get en set operaties op de MEB kunnen verwerken. Onderhoud aan de MIB, bijvoorbeeld bij modificatie van
Dit is echter geen agent in de zin van FIPA (zie hoofdstuk 2)
Datum 28 juni 2002 Onze referentie I&I-MEM-020750 Blad 10
Nederlandse Organisatie voor toegepast-natuurwetenschappelijk onderzoek / Netherlands Organisation for Applied Scientific Research
TNOTPD Memorandum
TH*
parameters, moeten alle componenten ook aangepast worden. Ervaring uit NTCIP ' leert dat deze benadering resulteert in leverancierafhankelijkheid en interoperabiliteit bemoeilijkt. In SNMP wordt interactie beschouwd als onafhankelijke communicatie handelingen tussen twee componenten. SNMP kent dus geen interactie protocollen anders dan get en set opdrachten, maakt geen onderscheid in soorten communicatieve handelingen, en onderkent geen content-languages. In dit document wordt een MIB voor een DMS gebruikt uit een studie van AVV 11 . Bijlage A toont een gedeelte van deze MIB als voorbeeld met twee DMS systemen (Signl , Sign2) bestaande uit een chassis of cabinet, een matrix area, en een text area om tekst te kunnen weergeven. Deze representatie bestaat uit drie tabellen. • Een physical entity tabel beschrijft fysieke bronnen in een management systeem. • Een logical entity tabel beschrijft logische entiteiten van een management systeem. • Een mapping tabel definieert de relaties tussen een physical table en een entity tabel.
4
XML - eXtensible Markup Language
In dit hoofdstuk worden de toepassingsmogelijkheden voor DVM van XML en gerelateerde talen en documenten beschreven. Het voorbeeld van de DMS MTB uit hoofdstuk 3 zal hierbij worden gebruikt ter illustratie van de mogelijkheden van XML. Om extra mogelijkheden met XML te illustreren is additionele informatie opgenomen die niet in het voorbeeld van hoofdstuk 3 of referentie n gegeven zijn. De voorbeeld documenten in bijlagen zijn dan ook niet gegeven als verdere uitwerking of ter vervanging van de MIB in referentie n .
4.1 De taal XML XML (eXtensible Markup Language) is een markup taal voor tekst, documenten of berichten. In XML wordt de generieke term document gebruikt om tekst documenten, strings, of berichten aan te geven. Hier zal de termen document als synoniem voor de term bericht in de zin van AVB worden gehanteerd. Een bericht, of document, is een gestructureerde verzameling van elementen, zoals Figuur 4, die gezamenlijk de inhoud vormen van het bericht. XML is een taal voor de formele definitie van data elementen en de hiërarchische structuur van deze elementen in een bericht. Het structureren van de elementen heet "markup". In een markup taal worden elementen van de inhoud van een bericht gekwalificeerd door er een etiket aan te verbinden. In XML terminologie is een etiket een "tag", en wordt gerepresenteerd door de naam van de kwalificatie omsloten door haken "<" of "".Een element wordt gemarkeerd met een begin-tag en een eind-tag, zoals in;
element<Jkwalificatie>
Datum 28 juni 2002 Onze referentie I&I-MEM-020750 Blad 11
TNOTPD
Nederlandse Organisatie voor toegepast-natuurwetenschappelijk onderzoek / Netherlands Organisation for Applied Scientific Research
Memorandum
Datum 28 juni 2002
Een element kan een enkelvoudig data element zijn of een complexe hiërarchische structuur hebben van sub-elementen. XML definieert een bericht in een standaard ASCII (Unicode) bestand of string (niet als binaire gegevens) en is daarmee zeer goed leesbaar voor personen en uitwisselbaar tussen software componenten. Er bestaat veel programmatuur om XML berichten te definiëren, en om ze elektronisch te genereren, lezen, verwerken, en te communiceren. Hoofdstuk 5 geeft enkele gereedschappen als voorbeeld. Bijlage B toont als voorbeeld een XML document voor de beschrijving van Signl van het Dynamic Message Sign (DMS) voorbeeld uit hoofdstuk 3 en bijlage A. In dit document is de leesbaarheid verhoogd door de hiërarchische structuur aan te geven met inspringen. In de MIB moet de informatie worden gestructureerd volgens de tabel definities. Hierdoor moeten de fysische en logische eigenschappen van de twee borden (Signl, Sign2) worden opgesplitst in twee tabellen en een relatie tabel. Deze structuur had ook in XML gebruikt kunnen worden. Om de flexibiliteit van XML te demonstreren is hier echter gekozen om de fysische en logische informatie per component (cabinet, textarea, matrixarea) te groeperen en te structureren. XML biedt de generieke mogelijkheid om specifieke tags voor specifieke toepassingsdomeinen te definiëren. Dit in tegenstelling tot bijvoorbeeld HTML (HyperText Markup Language), waarin een beperkt aantal tags zijn gedefinieerd, zoals en <head>. Daardoor kan voor ieder applicatie domein specifieke tags worden gedefinieerd, en is XML zeer geschikt als standaard voor het structureren van domein specifieke berichten. In 12,13 zijn vele toepassingsdomeinen te vinden als voorbeeld. In Bijlage B zijn bijvoorbeeld specifieke DMS tags gedefinieerd, zoals <sign>, <cabinet>, en <matrixarea>. Domeinspecifieke ontologieën zoals ebXML worden bij OASIS13 geregistreerd en voor andere partijen in hetzelfde domein beschikbaar gemaakt om de uitwisseling en eenduidige interpretatie van gegevens te faciliteren.<br />
<br />
4.2 XML gerelateerde talen en documenten De vrijheid die XML biedt voor het definiëren van tags vereist een standaardisatie om berichten uit te kunnen wisselen. In 12 zijn standaarden gegeven voor een groot aantal applicatie domeinen (zie ook sectie 4.3). In deze sectie worden enkele typen documenten beschreven die ontwikkeld zijn om op meta niveau de structuur en standaardisatie van XML documenten te specificeren, namelijk de DTD, XML Schema en RDF. Zo'n referentiekader wordt op de tweede regel van een XML bericht gespecificeerd. In Bijlage B wordt bijvoorbeeld de DTD van bijlage C opgegeven, maar hier kan ook een referentie naar een XML Schema of RDF ontologie staan. Evenals voor XML bestaat er al een grote verscheidenheid aan programmatuur om ook deze documenten elektronisch te behandelen (zie hoofdstuk 5).<br />
<br />
Onze referentie I&I-MEM-020750 Blad 12<br />
<br />
TNO TPD<br />
<br />
Nederlandse Organisatie voor toegepast-natuurwetenschappelijk onderzoek/Netherlands Organisation for Applied Scientific Research<br />
<br />
Memorandum<br />
<br />
4.2.1 DTD - Document Type Definition Om een standaard voor XML berichten af te dwingen wordt deze standaard in een apart document gedefinieerd - de zogenaamde Document Type Definition (DTD). In een DTD wordt de structuur van data elementen in combinatie met een vocabulaire van de toegestane markup tags gedefinieerd. Een DTD document fungeert als sjabloon voor het opstellen van een XML bericht zelf. Bijlage C toont een DTD voor het DMS voorbeeld. De syntax van een DTD verschilt met die van een XML bericht. In dit voorbeeld wordt voorgeschreven dat een DMS XML bericht onder andere de volgende structuur en inhoud moet hebben: • Een sign bestaat uit componenten: een cabinet, een textarea en/of een matrixarea. • De componenten hebben een fysische en logische informatie blok. • De attributen die een fysische en logisch blok respectievelijk moeten (#REQUIRED) of mogen hebben. Het XML bericht blijft een op zich zelf staand bericht, en kan zonder de DTD gewoon verwerkt en gelezen worden. De DTD moet gezien worden als een referentie document op basis waarvan het XML bericht beter elektronisch verwerkt kan worden. Met behulp van deze DTD kan de integriteit van het XML bericht uit bijlage B (automatisch) geverifieerd worden.<br />
<br />
4.2.2 XML Schema XML Schema is een nieuwe ontwikkeling waarin de mogelijkheden van een DTD worden uitgebreid 14. XML Schema is met name ontwikkeld om ook vocabulaires, of schema's, te definiëren. In een DTD kan geen informatie over de typen en waarden van de tags en elementen worden gespecificeerd. Een XML Schema representeert de vocabulaire, structuur én een deel van de semantiek (als een verzameling van beperkingen of business rules) voor een type XML documenten. Een XML Schema is, net als een DTD, een apart document en wordt opgesteld in de zogenaamde XML Schema definition language. De XML Schema taal bevat een gegeven aantal tags waarmee kan worden voorgeschreven; • de structuur van elementen, met hun substructuren en componenten, • de mogelijke of verplichte attributen met hun naam, type, data formaat, eenheid, en domein van mogelijke waarden, In tegenstelling tot een DTD is de XML Schema taal vergelijkbaar met XML zelf. Daarnaast biedt XML Schema meer data typen die compatibel zijn met bijvoorbeeld data typen in standaard databases, en de mogelijkheid om eigen data types te definiëren. De XML Schema taal is meer object georiënteerd dan DTD en biedt onder andere functionaliteit voor het specialiseren en uitbreiden van data typen, over-definiëren van elementen met een zelfde naam maar verschillende inhoud, en synoniemen voor elementnamen.<br />
<br />
Datum 28 juni 2002 Onze referentie I&I-MEM-020750 Blad 13<br />
<br />
TNO TPD<br />
<br />
Nederlandse Organisatie voor toegepast-natuurwetenschappelijk onderzoek / Netherlands Organisation for Applied Scientific Research<br />
<br />
Memorandum<br />
<br />
Bijlage D toont een voorbeeld van een schema voor de DMS. Het schema specificeert dezelfde structuur en inhoud van de DTD (bijlage C) zoals beschreven in sectie 4.2.1. Het schema is echter uitgebreider dan de DTD, en definieert bijvoorbeeld de data typen en het domein van de attributen; zie bijvoorbeeld het attribuut entPhysicalClass, van type integer met domein [1,9].<br />
<br />
4.2.3 RDF - Resource Description Framework Het Resource Description Framework (RDF) is een raamwerk dat oorspronkelijk is ontwikkeld voor de representatie van meta-data over internet bronnen (resources) en diensten om interoperabiliteit in uitwisseling van informatie via het web mogelijk te maken15. Er is een representatie van RDF in XML ontwikkeld. RDF kan worden gezien als een applicatie van XML die rijker is om ontologieën in XML te specificeren dan XML Schema. RDF specificeert de structurele beperkingen voor eenduidige methoden om semantiek in XML uit te drukken. RDF is echter zeer generiek en is bijvoorbeeld ook toegepast voor representatie van eenvoudige ontologieën, waarbij concept definities als metadata beschrijvingen worden beschouwd. Met RDF is het mogelijk om een structuur te specificeren voor het beschrijven van concepten binnen een bepaalde context. RDF is rijker dan XML schema's; XML schema's beschrijven alleen de structuur van een document, RDF biedt ook mogelijkheden om relaties over een concept te specificeren. Een relatie wordt gedefinieerd in de vorm van een predikaat, waarbij een relatie tussen twee objecten wordt benoemd door een label (predikaat). Een eenvoudige vorm van een predikaat is bijvoorbeeld een attribuut met waarde voor een element (zoals ook in een MTB, XML, DTD, of XML Schema). Voor het voorbeeld van de DMS kunnen we bijvoorbeeld zeggen dat het bord een fysieke locatie heeft. In RDF kan dit als volgt uitgedrukt worden, waarbij het element bord wordt gedefinieerd met een uri (uniform resource identifier) naar de "uri:entityMIB.xml": <rdf:RDFxmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <rdf:Description about="uri:entityMEB.xml"> <wegnummer>A 16</wegnummer> < wegzij de>N</wegzij de> <hectometeraanduiding> 124</hectometeraanduiding> <rijstrook>3</rij strook> </rdf:Description> </rdf:RDF> In een predikaat kan een attribuut ook vervangen worden door een ander element, en wordt een relatie over elementen gedefinieerd. De < wegnummer > kan bijvoorbeeld ook een element zijn, dat elders nader is gedefinieerd. Daarmee wordt de relatie expliciet gemaakt naar het element wegnummer. Bij de eerdere representaties zou deze relatie met waarde 3 impliciet zijn; d.w.z. dat een mens wel begrijpt dat het wegnummer A16 ene<br />
<br />
Datum 28 juni 2002 Onze referentie I&I-MEM-020750 Blad 14<br />
<br />
TNO TPD<br />
<br />
Nederlandse Organisatie voor toegepast-natuurwetenschappelijk onderzoek/Netheriands Organisation for Applied Scientific Research<br />
<br />
Memorandum<br />
<br />
object op zich is en geen integer waarde, maar dat er een speciale functie geschreven moet worden om deze "wegnummer A16" te vertalen naar een object. In RDF kunnen ook concepten worden gespecialiseerd, waarbij attributen en relaties worden overgeërfd en nieuwe attributen en relaties kunnen worden toegevoegd. Ook kunnen predicaten worden gedefinieerd en eerste orde logica in de vorm van regels. De extra betekenis die toegekend kan worden is het minimale niveau voor een implementatie van een ontologie. Om de ontologische kennisrepresentatie naar een hoger niveau te brengen is RDF met verschillende specificaties uitgebreid. RDF Schema (RDFS), DARPA Agent Markup Language (DAML) en Ontology Inference Layer (OEL) zijn hier voorbeelden van. DAML+ODL zijn inmiddels samengevoegd in de Ontology Web Language (OWL) 1.0 specificatie. Zie 16 voor referenties op het Internet.<br />
<br />
4.2.4 XSL Stylesheets Met XML wordt de structuur van een reeks gegevens gedefinieerd onafhankelijk van de uiteindelijke presentatie daarvan. Om een XML document te tonen aan een gebruiker wordt het middel een stylesheet naar een formaat getransformeerd dat presentatiespecifieke informatie bevat, zoals html of printer formaat. Daardoor kunnen dezelfde gegevens op verschillende manieren getoond worden, zoals een matrixbord of een DRIP van een bepaalde leverancier. Stylesheets worden met de eXtensible Stylesheet Language (XSL) beschreven 17. Een stylesheet is een apart document waarin de transformatie wordt gespecificeerd tussen twee typen XML berichten. De taal XSL is eigenlijk een XML vocabulaire voor formattering. Transformatie van XML documenten in andere documenten is een generiek proces voor alle soorten omzettingen van representaties en structuren van gegevens. Een stylesheet processor leest het XML bericht en de XSL stylesheet in, en transformeert de inhoud uit het XML bericht naar het gewenste formaat. Stylesheet processoren zijn beschikbaar voor vele gangbare transformaties. De omzetting van een XML data definitie naar een CORBA IDL is een voorbeeld hiervan (zie paragraaf 5.4). Een XML bericht kan ook getransformeerd worden naar een XML bericht van een ander type en met een ander vocabulaire, bijvoorbeeld om een generiek bericht tot activatie van een verkeersmaatregel te transformeren naar de specifieke representatie van een leverancier voor de activatie van een beeld op een dynamisch bord. Voor transformatie tussen XML berichten is een specifieke taal beschikbaar; de XSL Transformation language of XSLT 18<br />
<br />
4.3 Syntax en semantiek in XML In deze sectie worden voorafgaande secties samengevat ter beantwoording van de vraag wat kan wel en niet gedefinieerd kan worden met XML. XML biedt middelen om hiërarchisch gestructureerde gegevens door markup te beschrijven. Gebaseerd op de basis XML-middelen (de XML specificatie zelf, DTD's en<br />
<br />
Datum 28 juni 2002 Onze referentie I&I-MEM-020750 Blad 15<br />
<br />
Nederlandse Organisatie voor toegepast-natuurwetenschappelijk onderzoek ƒ Netherlands Organisation for Applied Scientific Research<br />
<br />
TNO TPD<br />
<br />
Memorandum<br />
<br />
TH*<br />
<br />
schema's) zijn er een aantal lagen gedefinieerd van talen die meer aspecten van een domein kunnen beschrijven (zie Figuur 5). Afhankelijk van de gebruikte taal kan er dus een mindere of rijkere beschrijving van een domein gegeven worden.<br />
<br />
Datum 28 juni 2002 Onze referentie I&I-MEM-020750 Blad 16<br />
<br />
describing document<br />
<br />
Resource Description Framework + RDF Schema<br />
<br />
l|ö||i|ilp(|^i||^||sj Unicode<br />
<br />
Universal resource indicator<br />
<br />
Figuur 5 Lagen van semantische beschrijving<br />
<br />
Zoals al getoond zijn DTD's redelijk beperkt tot de structuur van een document. Met schema's kan meer structuur aangegeven worden met complexe data types. RDF biedt een model om resources en hun eigenschappen in statements te beschrijven (triplets van resources, properties, statements). In een statement over resources kan weer naar andere resources worden verwezen. In OWL zijn er nog meer voorzieningen om bijvoorbeeld de cardinaliteiten van relaties aan te geven (aantal relaties tussen concepten). RDF wordt zelf door middel van XML in RDF Schema (RDFS) beschreven, dus alle hier genoemden talen grijpen terug naar de basis XML syntax en kunnen daarom met gestandaardiseerde tools (parsers) verwerkt worden. Het gebruik van de passende taal is afhankelijk van het domein, maar voor het definiëren van semantiek in een systeem moet er minimaal op het niveau "Ontology Vocabulary" (in Figuur 5) worden gespecificeerd. Zoals eerder al aangegeven horen bij een systeemontwerp naast ontologieën ook regels (logic) en interactieprotocollen.<br />
<br />
4.4 DVM-specifieke XML-toepassingen XML wordt in vele applicatie domeinen al veelvuldig toegepast. Ook voor verkeerskundige applicaties wordt XML toegepast, met name voor uitwisseling van verkeersinformatie tussen verkeerscentrales en voor publieke toepassing op het web. De DATEX standaard wordt veel gebruikt voor communicatie van verkeersinformatie, bijvoorbeeld door het TIC (Traffic Information Center). DATEX is gebaseerd op EDIFACT, een standaard uit de financiële sector. In deze sector wordt EDEFACT geleidelijk aan vervangen door XML gebaseerde varianten zoals ebXML en BizTalk (zie 1 ). Het lijkt waarschijnlijk dat ook DATEX zal worden vervangen door een XML variant.<br />
<br />
Nederlandse Organisatie voor toegepast-natuurwetenschappelijk onderzoek / Netherlands Organisation for Applied Scientific Research<br />
<br />
TNO TPD Memorandum<br />
<br />
Het Regiolab is een samenwerkingsverband tussen TU Delft, Rijkswaterstaat, Provincie Zuid-Holland, Connekt, Vialis en Siemens. In het project XML for traffic data exchange19 wordt XML gebruikt voor de uitwisseling van real-time verkeersinformatie naar reizigers via het internet. Integratie van gedistribueerde verkeersinformatie in verschillende formaten en van verschillende bronnen, waaronder informatie van het TIC in DATEX, blijkt moeilijk te zijn. Een van de doelstellingen in dit project is om te onderzoeken of XML een goed alternatief is voor het gebruik en integratie van deze informatie bronnen. In dit project wordt de informatie vanuit verschillende bronnen en representaties geaggregeerd en geconverteerd naar XML, en van daaruit naar verschillende formaten getransformeerd voor verschillende interactie media, zie Figuur 6.<br />
<br />
Figuur 6 XML voor verkeersdata uitwisseling (bron 19) 20<br />
<br />
XML wordt ook gebruikt voor verkeersinformatie in het UTMC29B project in Reading en in verschillende staten van de VS. In Oregon in TripCheck 21 en CARS511 22 in Alaska bijvoorbeeld wordt XML gebruikt voor interne representatie en getransformeerd naar html pagina's . Een ander voorbeeld is Triplnfo , waarin XML wordt gebruikt om verkeersinformatie te koppelen met route-informatie, zoals weersverwachtingen, werkzaamheden, en weggesteldheid om een geïntegreerd reisadvies te kunnen genereren. XML wordt gebruikt om de informatie uit verschillende bronnen te integreren. De resultaten uit dit project zijn voorgelegd aan de Society of Automotive Engineers (SAE) voor de ontwikkeling van een XML standaard en XML Schema voor Traveler Information Markup Language TIML24. In 'the Internet Applications Project' 25 zijn verschillende Noord-Amerikaanse participanten betrokken bij de ontwikkeling van een Traffic Data XML Data Schema (TDML). TDML heeft eveneens als doel om verkeersgegevens te kunnen uitwisselen tussen verschillende agentschappen, applicaties en mobiele apparaten.<br />
<br />
Datum 28 juni 2002 Onze referentie I&I-MEM-020750 Blad 17<br />
<br />
TNO TPD<br />
<br />
Nederlandse Organisatie voor toegepast-natuurwetenschappelijk onderzoek / Netherlands Organisation for Applied Scientific Research<br />
<br />
Memorandum<br />
<br />
Datum 28 juni 2002<br />
<br />
5<br />
<br />
Tools en toepassingen<br />
<br />
5.1 Modelleer en specificatie tools Wanneer men er voor kiest om datadefïnities in XML te modelleren bieden XMLeditors mogelijkheden om dit proces te vereenvoudigen. Er zijn veel tools op de markt verkrijgbaar voor het creëren en valideren van XML documenten, DTD's, schema's en stylesheets. Deze zijn zowel commercieel als open source verkrijgbaar. Een populaire tooi is XML Spy van de firma Altova. Met deze tooi kunnen XML documenten, DTD's en schema's gelezen, geschreven en gevalideerd worden. Het biedt verschillende views op een XML document. Bijlage E en G tonen een schermafdruk respectievelijk het XML bericht en het XML Schema in XML Spy. XmetaL 27 van de firma SoftQuad en TurboXML 28 van de firma TIBCO zijn meer georiënteerd op Web-publishing dan op pure XML-editing. Protégé 200029 is een standaard open source tooi voor het bouwen van een ontologie. Deze tooi biedt de volgende mogelijkheden: • • • •<br />
<br />
Concepten beschrijven aan de hand van een klasse hiërarchie Toekennen van eigenschappen aan de concepten Relaties leggen tussen verschillende concepten Constraints (beperkingen) definiëren die bepalen welke relaties wel of niet mogen voorkomen en in welke cardinaliteiten (hoeveelheden).<br />
<br />
Protégé 2000 biedt mogelijkheden om de ontologieën te exporteren naar XML DTD's, schema's en RDF/RDFS. Door middel van plugin architectuur kunnen software ontwikkelaars eigen functionaliteiten aan de tooi toevoegen. Bijlage F toont een schermafdruk van Protégé 2000 waarbij enkele concepten uit de AVB architectuur zijn opgenomen.<br />
<br />
5.2 Standaard parsers, transformatie en andere libraries Hoewel XML van oorsprong bedoeld is om voor mensen leesbare documenten te beschrijven, wordt XML steeds meer toegepast als uitwisselings- of opslagformaat van data. XML is niets anders dan een passief formaat om data te coderen. De kracht ligt in de combinatie van XML en parsing (het ontleden) technologie om zodoende een XML structuur te kunnen: • • • •<br />
<br />
Benaderen Valideren Manipuleren Transformeren<br />
<br />
Onze referentie I&I-MEM-020750 Blad 1R<br />
<br />
TNO TPD<br />
<br />
Nederlandse Organisatie voor toegepast-natuurwetenschappelijk onderzoek/Netherlands Organisation for Applied Scientific Research<br />
<br />
Memorandum<br />
<br />
Parsers en transformatie processors (transformeren een XML structuur naar een andere XML structuur) worden vaak geïmplementeerd in standaard programmeer talen zoals C++ en Java. XML ligt daarom zeer dicht tegen deze standaard talen. De meest gebruikte modellen om een XML structuur te benaderen zijn het Document Object Model (DOM)30 en de Simple API for XML (SAX)31. Het DOM model representeert een XML document als een boomstructuur in het interne geheugen van een computer. De boom kan vervolgens doorlopen worden om elk element te benaderen. Dit model is voornamelijk geschikt voor het parsen van kleine XML bestanden aangezien bij grote XML-documenten het geheugengebruik snel toeneemt. Het SAX-model loopt een XML-document sequentieel af. Bij elk element dat langsgelopen wordt kan een te ondernemen actie gedefinieerd worden. Het SAX model is vooral geschikt voor het manipuleren van grote XML-documenten. Er wordt minder beslag gelegd op het interne geheugen dan bij gebruik van het DOM-model. Er zijn vele standaard producten voor editeren, parsing, validatie en transformatie van XML documenten. Deze zijn zowel commercieel als open source (bijvoorbeeld de Apache Software Foundation 32 ) verkrijgbaar. Zie33 voor verwijzingen naar enkele standaard producten.<br />
<br />
5.3 XML databases Wanneer data definities, berichten of configuratiegegevens voor langere tijd beschikbaar moeten zijn kunnen deze worden opgeslagen in een database. XML biedt zelf geen mogelijkheden om met databases te werken aangezien dit buiten de doelstellingen van XML valt. XML houdt zich bezig met het beschrijven van hiërarchische data, niet met de manier hoe de data wordt opgeslagen. De XML Query standaard specificatie is van belang om XML documenten te benaderen wanneer XML documenten in een relationele database worden opgeslagen. Native XML databases zijn databases die XML documenten in de oorspronkelijke vorm opslaan. Dit kan in de vorm van geïndexeerde tekstbestanden of in de vorm van een mapping van het XML Document Object Model (DOM) naar een onderliggend dataopslag formaat. Er zijn veel XML database implementaties op de markt verkrijgbaar. Zowel commercieel als open source. Zie34 voor een overzicht van de meest voorkomende implementaties. Een bekend commercieel XML database pakket is Tamino van de firma Software AG. Een bekende open source implementatie is Xindeces van Apache.<br />
<br />
Datum 28 juni 2002 Onze referentie I&I-MEM-020750 Blad 19<br />
<br />
Nederlandse Organisatie voor toegepast-natuurwetenschappelijk onderzoek / Netherlands Organisation for Applied Scientific Research<br />
<br />
TNO TPD<br />
<br />
Memorandum<br />
<br />
TB#<br />
<br />
5.4 XML en CORBA/IDL Hoe kan XML gecombineerd worden met CORBA/IDL en wat zijn de voordelen van deze combinatie? Een mogelijk scenario is de situatie waarbij CORBA wordt gebruikt aan het wegkantstation of in de Verkeerscentrale en een XML-document (gebaseerd op een DTD of schema) wordt ingezet als inhoud van CORBA berichten. De leveranciers van wegkantsystemen of van verkeerscentrale applicaties kunnen deze XML-documenten direct inlezen en genereren in hun applicaties door ze te parsen (zie hoofdstuk 5.1) en gebruiken voor verdere aansturing/processing aan de wegkantapparatuurzijde. Bij deze benadering is het niet noodzakelijk om een complete CORBA API te definiëren die bepaald welke operaties en berichtversturing mogelijk is voor de verschillende CORBA componenten. De definities en specificaties liggen namelijk al vast in de XML documenten. Voor een vergelijkbare oplossing is gekozen in het COURIER project, maar dan nog met DATEX en CORBA35. Een ander scenario is het gebruik van een XML definitie in combinatie met CORBA IDL data types. Dit biedt voordelen als datadefmities al vastliggen en er sprake is van een migratietraject naar CORBA. Via een mapping van XML naar IDL datatypes kan een CORBA implementatie op een gestandaardiseerde manier direct toegang krijgen tot de volledige informatie van een XML document. De Object Management Group (OMG36) heeft hiertoe een specificatie ontwikkeld om een mapping gebaseerd op XML DTD's te kunnen realiseren 37 Voor zover bekend zijn er nog geen tools op de markt beschikbaar die gebruik maken van deze specificatie. In dit geval moet er rekening gehouden worden met extra kosten voor het ontwikkelen van een implementatie die gebruik maakt van deze OMG specificatie.<br />
<br />
6<br />
<br />
Hoe verschilt XML van MIB<br />
<br />
In hoofdstuk 3 is beschreven wat MIB's zijn en hoe deze worden toegepast voor DVM. De data en definities in een MIB kunnen echter ook in XML en gerelateerde documenten gerepresenteerd worden, zoals is aangegeven in hoofdstuk 4. In hoofdstuk 3 is onderscheid gemaakt tussen de specificatie van een M B in ASN.1, de generatie en verwerking van datastromen voor communicatie via een MIB, en het netwerk communicatie van de datastromen. Een vergelijkbaar onderscheid kan worden gemaakt voor XML gerelateerde documenten. 1. Voor specificatie van data definities voor XML berichten zijn enkele talen en document typen beschikbaar. De DTD is de meest eenvoudige taal, waarin de hiërarchische structuur van objecten (elementen) voorgeschreven kan worden (bijlage C). DTD's verschillen ten opzichte van MIB's in het feit dat tussentabellen om relaties te kunnen definiëren niet nodig zijn.In een DTD kunnen echter geen validiteitsdomein voor parameters worden gedefinieerd zoals in ASN.1. XML Schema's zijn daarentegen krachtiger en bieden meer expressiviteit dan ASN.1 voor bijvoorbeeld het definiëren van nieuwe data typen.<br />
<br />
Datum 28 juni 2002 Onze referentie I&I-MEM-020750 Blad 20<br />
<br />
Nederlandse Organisatie voor toegepast-natuurwetenschappelijk onderzoek/Netherlands Organisation for Applied Scientific Research<br />
<br />
TNO TPD<br />
<br />
Memorandum<br />
<br />
TK9<br />
<br />
Het is ook mogelijk om semantische relaties tussen objecten te definiëren. Het toekennen van betekenis aan deze objecten voorkomt dubbelzinnigheid wanneer informatie over deze objecten onderling wordt uitgewisseld. Dit is een voordeel ten opzichte van MIB's. In sectie 4.2.3 is aangegeven hoe een ontologie en begrippenkader van een applicatie domein opgesteld en gerepresenteerd kan worden in bijvoorbeeld RDF XML. Vanuit deze ontologie kan vervolgens een data definitie worden afgeleid. 2. Zowel een MIB als een XML bericht zullen specifiek worden opgesteld voor een specifiek apparaat. De specificatie zal dus sterk gerelateerd zijn aan een leverancier, product en product serie. In beide gevallen zullen software modulen geïntegreerd moeten worden met de DVM componenten voor het genereren en verwerken van de gegevensstromen. Er is echter een belangrijk verschil tussen MTBs en XML. XML, DTD, schema's en RDF zijn breed geaccepteerde standaarden waarvoor standaard tools beschikbaar zijn die volledig worden geconfigureerd door de XML gerelateerde documenten. Daarmee wordt het onderhoud gereduceerd tot het onderhouden van de XML gerelateerde documenten. De modulen voor een MIB daarentegen, moeten door een leverancier opnieuw gemaakt, gedistribueerd en geïntegreerd worden in de componenten. 3. De XML gerelateerde talen en documenten zijn in principe onafhankelijk van een te kiezen netwerk communicatie protocol zoals SNMP. Veelal worden breed geaccepteerde standaarden toepast zoals http. Het is echter ook mogelijk om op applicatie niveau te communiceren, bijvoorbeeld via CORBA. Met name uit punten 2 en 3 blijkt dat XML technische voordelen biedt indien een begrippenkader of ontologie gedefinieerd moet worden voor het DVM domein, om van daaruit meer consistente data definities te genereren voor specifieke DVM apparatuur. Het belangrijkste verschil is wellicht de graad van standaardisatie. XML is een wereldwijd geaccepteerde standaard met zeer breed toepassingsdomein en ondersteuning in de vorm van tools. Dit laat toe om communicatie inhoudelijk te specialiseren voor DVM toepassingen en tegelijkertijd het communicatie proces technisch te ondersteunen en generieke tools. XML faciliteert interoperability in hoge mate, en beperkt de afhankelijkheid van leverancier-specifieke communicatie oplossingen. In 10 is een vergelijking gemaakt tussen onder andere DATEX-ASN (gebruik makend van MIB) en XML voor center-to-center communicatie in NTCIP. De belangrijkste conclusie is hier relevant; standaardisatie van data definities en formaten is met beide technologieën mogelijk, DATEX-ASN impliceert echter de hoogste ontwikkelingskosten en leidt tot monolithische, domein of leverancier specifieke systemen.<br />
<br />
7 1<br />
<br />
3<br />
<br />
5 6<br />
<br />
Referenties De AVB Informatie Architectuur - Produkt P.IA.pl, J. Blonk, P. Meij, J. Rogier, D. de Winter, AVB, versie 1.6, 17 oktober 2000. AVB bureau website: http://www.minvenw.nl/rws/avv/avb/ Marktverkenning Componenten DVM-systeem. Uitgevoerd door TJ. Grant, R. Moerman, B.D. Netten in opdracht van A W . Concept versie 1.1, 15 juli 2002. FIPA, Foundation for Intelligent Physical Agents, http://www.fipa.org/ OMG, Object Management Group, http://www.omg.org/ http://www.fipa.org/specs/fipa00001/XC00001J.html<br />
<br />
Datum 28 juni 2002 Onze referentie I&I-MEM-020750 Blad 21<br />
<br />
Nederlandse Organisatie voor toegepast-natuurwetenschappelijk onderzoek /Netherlands Organisation for Applied Scientific Research<br />
<br />
n* r\ TT» TNO TPD ^<br />
<br />
Memorandum<br />
<br />
^<br />
<br />
T.H9 Datum 28 juni 2002<br />
<br />
8 9 10 11<br />
<br />
12 13 14<br />
<br />
15<br />
<br />
16<br />
<br />
17<br />
<br />
18 19<br />
<br />
20 21<br />
<br />
22 J<br />
<br />
24<br />
<br />
25 26<br />
<br />
28 29 30 31 32 33<br />
<br />
34 35<br />
<br />
36 37<br />
<br />
SOAP, Simple Object Access Protocol, W3C note version 1.1, mei 2000, http://www.w3 .org/TR/SOAP/ http://www.fipa.org/specs/fipa00027/XC00027F.html http://www.rad.com/networks/1995/snmp/snmp.htm http://www.its.washington.edu/bbone/ASNlWhitePaper-1 .html MIB based dynamic messages signs, interface requirements specifications (IRS) Transport Research Centre ( A W ) Enkele hyperlinks over XML: http://www.w3.org/XML/, http://www.oasis-open.org/ Enkele hyperlinks over XML schema's: http://www.w3.org/XML/Schema, http://www.w3.org/TR/xmlschema-0/, http://www.xfront.com/ Enkele hyperlinks over RDF: http://www.w3.org/RDF/, http://www7 lO.univ-lyon 1 .fr/~champin/rdf-tutorial/ Enkele hyperlinks over DAML, OIL en OWL: http://www.w3.org/2001/sw/WebOnt/, http://www.daml.org/, http://ontolingua.stanford.edu/ Enkele hyperlinks over XSL: http://www.w3.org/TR/xsl, http://www.w3.org/TR/xpath, Specificatie van XSL Transformation language XSLT, http://www.w3.org/TR/xslt XML for Traffic Data Exchange, TRAIL, http://cttrailf.ct.tudelft.nl/verkeerskunde/staff/kirwan/about.html http://www.utmc.dft.gov.uk/utmc29/utmc29.htm TripCheck, verkeersinformatie site van de Oregon Department of Transportation, http://www.tripcheck.com/ C A R S 5 1 1 , Alaska D o T , http://www.alaskaits.com/hold/CARS and 511.pdf Triplnfo: Integrating Traveler Information Using XML, M.F. McGurrin et al., http://www.mitretek.org/its/TripInfo.pdf T I M L Traffic Information Markup Language, A T I S X M L draft recommendation, S A E , http://forums.sae.org/access/dispatch.cgi/TEITSATISpf/docProfile/100076 http://www.travelerinformation.com/ http://www.xmlspy.com/ http://www.softquad.com/products/xmetal/ httpV/www.tibco.com/solutions/products/extensibility/ http://protege.stanford.edu/ http://www.devguru.com/Technologies/xmldorn/quickref/xmldom intro.html http://www.saxproject.org/ http://www.apache.org/ Xerces - een standaard open source X M L parser voor Java/C++, http://xml.apache.org/xerces-i/index.html Xalan - een standaard open source X M L stylesheet processor voor Java/C++, http://xml.apache.org/xalan-i/index.html X M L Booster - een commerciële X M L parser voor Java/C/C++/Cobol/Delphi, http://www.xmlbooster.com/ http://www.rpbourret.com/xml/XMLDatabaseProds.htmtfnative http://members.traffic-wales.com/courier/Courier%20TIHDATEX%20Proiect%20%20Architecture%20Summary%202.pdf http://www.omg.org/ http://cgi.omg.org/docs/ptc/01-04-04.pdf<br />
<br />
Onze referentie I&I-MEM-020750 Blad<br />
<br />
22<br />
<br />
TNO TPD<br />
<br />
Memorandum<br />
<br />
Nederlandse Organisatie voor toegepast-natuurwetenschappelijk onderzoek / Netheriands Organisation for Applied Scientific Research<br />
<br />
TK9 Datum 28 juni 2002<br />
<br />
Bijlage A: MIB - Management Information Base<br />
<br />
Onze referentie I&I-MEM-020750<br />
<br />
EntPhysicalTable<br />
<br />
Blad 23<br />
<br />
-- Signl device chassis: entPhysicalDescr. 1 == "Cabinet signl" entPhysicalVendorType.1 == manufacturer.Sign.5 entPhysicalContainedln.1 ==0 entPhysicalClass.1 ==5 (container) entPhysicalParentRelPos.1 = 0 entPhysicalName.1 = ' A 1 2 - 1 ' -- Signl text area: entPhysicalDescr.2 = "One line of text in signl" entPhysicalVendorType.2 == manufacturer.Text.3 entPhysicalContainedln.2 == 1 entPhysicalClass.2 == 9 (module) entPhysicalParentRelPos.2 == 1 (first module from top) entPhysicalName.2 == 'A12-1-Text' -- Signl matrix area: entPhysicalDescr.3 == "Full matrix area in signl" entPhysicalVendorType.3 = manufacturer.Matrix.11 entPhysicalContainedln.3 == 1 entPhysicalClass.3 == 9 (module) entPhysicalParentRelPos.3 = 2 (second module from top) entPhysicalName.3 = 'A12-1-Matrix' — Sign2 device chassis: entPhysicalDescr.4 = "Cabinet sign2" entPhysicalVendorType.4 == manufacturer.Sign.12 entPhysicalContainedln.4 == 0 entPhysicalClass.4 = 5 (container) entPhysicalParentRelPos.4 == 0 entPhysicalName.4 = 'A12-2' — Sign2 matrix area: entPhysicalDescr.5 = "Full matrix area in sign2" entPhysicalVendorType.5 == manufacturer.Matrix.1 entPhysicalContainedln.5 == 4 entPhysicalClass.5 == 9 (module) entPhysicaiParentRelPos.5 = 1 (first module) entPhysicalName.5 == 'A12-2-Matrix'<br />
<br />
TNO TPD<br />
<br />
Memorandum<br />
<br />
Nederlandse Organisatie voor toegepast-natuurwetenschappelijk onderzoek / Netherlands Organisation for Applied Scientific Research<br />
<br />
TH* Datum 28 juni 2002<br />
<br />
EntLogicalTable -- Signl, the cabinet itself and its text and matrix area entLogicalDescr.1 == "Signl" entLogicaltvpe.1 ==TS3.6 entLogicalComunity.1 == "public-signi" entLogicalDescr.2 = "Signl text" entLogicaltype.2 == TS3.6 entLogicalComunity.2 == "public-texti" entLogicalDescr.3 == "Signl matrix" entLogicaltype.3 = TS3.6 entLogicalComunity.3 == "public-matrixr entLogicalDescr.4 == "Signl matrix" entLogicaltype.4 = AVV DMS entLogicalComunity.4 = "public-matrixi" -- Sign2, the cabinet itself and its matrix area entLogicalDescr.5 == "Sign2" entLogicaltype.5 == TS3.6 entLogicalComunity.5 == "public-sign2" entLogicalDescr.6 = "Sign2 matrix" entLogicaltype.6 = TS3.6 entLogicalComunity.6 == "public-matrix2" entLogicalDescr.7 == "Sign2 matrix" entLogicaltype.7 == AVV DMS entLogicalComunity.7 == "public-matrix2"<br />
<br />
EntMappingTable -- Signl -> Cabinet signl entLPPhysicallndex.1.1 == 1 - Signl text -> One line of text signl entLPPhysicallndex.2.2 == 2 - Signl matrix -> Full matrix area in signl entLPPhysicallndex.3.3 = 3 entLPPhysicallndex.4.3 == 3 -- Sign2 -> Cabinet sign 2 entLPPhysicallndex.5.4 == 4 — Sign2 matrix -> Full matrix area in sign2 entLPPhysicallndex.6.5 == 5 entLPPhysicallndex.7.5 == 5<br />
<br />
Onze referentie I&I-MEM-020750 Blad 24<br />
<br />
TNO<br />
<br />
Nederlandse Organisatie voor toegepast-natuurwetenschappelijk onderzoek / Netheriands Organisation for Applied Scientific Research<br />
<br />
TPD<br />
<br />
Memorandum<br />
<br />
TH* Datum 28 juni 2002<br />
<br />
Bijlage B: XML - eXtended Markup Language J<br />
<br />
a<br />
<br />
r<br />
<br />
s><br />
<br />
s><br />
<br />
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE entityMIB SYSTEM "entityMB.dtd"> <entityMTB> <sign> <cabinet> <entPhysicalTable entPhysicalDescr="Cabinet signl" entPhysicalVendorType="manufacturer.Sign.5" entPhysicalContainedIn="0" entPhysicalClass="5" entPhysicalParentRelPos="0" entPhysicalName="A 12-1 "/> <entLogicalTable entLogicalDescr="Sign 1" entLogicaltype="TS3.6" entLogicalCommunity="public-sign 1 "/> </cabinet> <textarea> <entPhysicalTable entPhysicalDescr="One line of text in signl" entPhysicalVendorType="manufacturer.Text.3" entPhysicalContainedIn=" 1" entPhysicalClass="9" entPhysicalParentRelPos=" 1" entPhysicalName=" A12-1-Text"/> <entLogicalTable entLogicalDescr="Signl text" entLogicaltype="TS3.6" entLogicalCommunity="public-tex 1 "/> </textarea> <matrixarea> <entPhysicalTable entPhysicalDescr="Full matrix area in signl" entPhysicalVendorType="manufacturer.Matrix. 11" entPhysicalContainedIn=" 1" entPhysicalClass="9" entPhysicalParentRelPos="2" entPhysicalName=" A12-1 -Matrix 7> <entLogicalTable entLogicalDescr= "Signl matrix" entLogicaltype="TS3.6" entLogicalCommunity="public-matrix 1 "/> <entLogicalTable entLogicalDescr="Signl matrix" entLogicaltype="AVV DMS" entLogicalCommunity="public-matrix 1 "/> </matrixarea> </sign> </entityMIB><br />
<br />
onze referentie I&I-MEM-020750<br />
<br />
f*A<br />
<br />
TNO<br />
<br />
Nederlandse Organisatie voor toegepast-natuurwetenschappelijk onderzoek / Netherlands Organisation for Applied Scientific Research<br />
<br />
TPD<br />
<br />
Memorandum<br />
<br />
TH* Datum 28 juni 2002<br />
<br />
Bijlage C: DTD - Document Type Definition '<br />
<br />
S<br />
<br />
'<br />
<br />
r<br />
<br />
<?xml version="1.0" encoding="UTF-8"?><br />
<br />
onze referentie I&I-MEM-020750<br />
<br />
^ 26<br />
<br />
<!ELEMENT entityMTB (sign+)> <!ELEMENT sign (cabinet, (textarea | matrixarea) *)> <!ELEMENT cabinet (entPhysicalTable, entLogicalTable)> <!ELEMENT textarea (entPhysicalTable, entLogicalTable+)> <!ELEMENT matrixarea (entPhysicalTable, entLogicalTable+)> <!ELEMENT entPhysicalTable EMPTY> <!ATTLIST entPhysicalTable entPhysicalDescr CDATA #REQUIRED entPhysicalVendorType CDATA #REQUIRED entPhysicalContainedln CDATA #REQUIRED entPhysicalClass CDATA #REQUIRED entPhysicalParentRelPos CDATA #REQUIRED entPhysicalName CDATA #REQUIRED > <!ELEMENT entLogicalTable EMPTY> <!ATTLIST entLogicalTable entLogicalDescr CDATA #REQUIRED entLogicaltype CDATA #REQUIRED entLogicalCommunity CDATA #REQUIRED<br />
<br />
d<br />
<br />
TNO<br />
<br />
TPD<br />
<br />
Memorandum<br />
<br />
Nederlandse Organisatie voor toegepast-natuurwetenschappelijk onderzoek /Netherlands Organisation for Applied Scientific Research<br />
<br />
TH» Datum 28 juni 2002<br />
<br />
Bijlage D: XML Schema J<br />
<br />
3<br />
<br />
Onze referentie I&I-MEM-020750 Blad<br />
<br />
<?xml version=" 1.0" encoding="UTF-8"?> 27 <xs:schema xmlns:xs=http://www. w3.org/2001/XMLSchema elementFormDefault="qualified"> <xs:complexTypename="cabinetType"> <xs:sequence> <xs:element name="entPhysicalTable" type="entPhysicalTableType"/> <xs:element name="entLogicalTable" type="entLogicalTableType"/> </xs:sequence> </xs:complexType> <xs:complexType name="entLogicalTableType"> <xs:attribute name="entLogicalDescr" type="xs:string" use="required"/> <xs:attribute name="entLogicaltype" type="xs:string" use="required"/> <xs:attribute name="entLogicalCommunity" type="xs:string" use="required"/> </xs:complexType> <xs:complexTypename="entPhysicalTableType"> <xs:attribute name="entPhysicalDescr" type="xs:string" use= "required"/> <xs:attribute name="entPhysicalVendorType" type="xs:string" use="required"/> <xs:attribute name="entPhysicalContainedIn" type="xs:string" use="required"/> <xs:attribute name="entPhysicalClass" use="required"> <xs:simpleType> <xs:restriction base="xs:integer"> <xs:minlnclusive value="17> <xs:maxlnclusive value="9"/> </xs:restriction> </xs: simpleTyp» </xs:attribute> <xs:attribute name="entPhysicalParentRelPos" type="xs:string" use="required"/> <xs:attribute name="entPhysicalName" type="xs:string" use="required"/> </xs:complexType> <xs:element name="entityMIB"> <xs:complexType> <xs:sequence> <xs:element name="sign" type="signType" maxOccurs="unbounded"/> </xs:sequence> </xsxomplexType> </xs:element> <xs:complexTypename="matrixareaType"> <xs:sequence> <xs:element name="entPhysicalTable" type="entPhysicalTableType"/> <xs:element name="entLogicalTable" type="entLogicalTableType" maxOccurs="unbounded"/> </xs:sequence> </xs: complexTypo <xs:complexType name="signType"> <xs:sequence> <xs:element name="cabinet" type="cabinetType"/> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element name="textarea" type="textareaType"/> <xs:element name="matrixarea" type="matrixareaType"/> </xs:choice> </xs:sequence> </xs:complexType><br />
<br />
TNO<br />
<br />
TPD<br />
<br />
Nederlandse Organisatie voor toegepast-natuurwetenschappelijk onderzoek /Netherlands Organisation for Applied Scientific Research<br />
<br />
Memorandum<br />
<br />
Datum 28 juni 2002 On/e referentie I&I-MEM-020750 Blad 28<br />
<br />
<xs:complexTypename="textareaType"> <xs:sequence> <xs:element name="entPhysicalTable" type="entPhysicalTableType"/> <xs:element name="entLogicalTable" type="entLogicalTableType" maxOccurs="unbounded"/> </xs:sequence> </xs :complexType> </xs:schema><br />
<br />
Nederlandse Organisatie voor toegepast-natuurwetenschappelijk onderzoek / Netheriands Organisation fox Applied Scientific Research<br />
<br />
TNO TPD Memorandum<br />
<br />
Datum 28 juni 2002<br />
<br />
Bijlage E: schermafdruk van XML in XML Spy<br />
<br />
Onze referentie I&I-MEM-020750 Blad 29<br />
<br />
; Be E<* E™>" S * BTDISdma<br />
<br />
Srtemadosign XSL DoqfimtEdUr<br />
<br />
£cnvnt s e » fronser Soap T a * ïhdow a *<br />
<br />
«53 ;B £fr£:S;S i<tH!ï? Q<br />
<br />
New Pioiect" < j£j XML Files "[Si XSL Fles iïfi HTMLFtes m DTO/Schemas<br />
<br />
^3<br />
<br />
o o <)<br />
<br />
13-MtltoUtC s;MttitMit«Gr0up x*:«iyAftribut»<br />
<br />
O : xmlnuxsf<br />
<br />
o o oo o{ ><br />
<br />
http:Mvww.w3.org/2001A<MLScharr)a-instar<ce<br />
<br />
SS «ntityMIg<br />
<br />
= = = = =<br />
<br />
•.•,:cwiii<l*.*':v.iirviir •-.:yioiil> i:.ill n:s*qu*nce<br />
<br />
4b«tl4Ct Moch flnat W mucd<br />
<br />
ADoendPi^trAdd^^dl HMM<br />
<br />
irtxed tWstW»is - " Jtsundedtivaknostal toatwBtt*Ue« smother m«mespitca»tol»<br />
<br />
i£janttyMIBZ.xiri S ert*yHlB2-x«J f WLSpyv4.4U Regbter«<Jto£pldermfln(b7ptsn) ©1998-2002Wtova'5n*HBtAftova,Inc.<br />
<br />
aB«*rtlll si B SJ 3 as j ] ^ 2 ^ _<br />
<br />
la*w<br />
<br />
|^«y<br />
<br />
I 1 ^fccrobatRaadef 5.0.5 | gAdobePhotwhop<br />
<br />
||^XHt^»y<br />
<br />
ÜÜMl<br />
<br />
jUKIi».^«^il|9® 1 0 = 0 8<br />
<br />
Nederlandse Organisatie voor toegepast-natuurwetenschappelijk onderzoek / Netherlands Organisation for Applied Scientific Research<br />
<br />
TNO TPD Memorandum<br />
<br />
TK* Datum 28 juni 2002<br />
<br />
Bijlage F: schermafdruk van Protégé 2000<br />
<br />
Onze referentie I&I-MEM-020750 Blad 30<br />
<br />
Protégé-2000 Project Edtt W M o w<br />
<br />
.=jaL2i<br />
<br />
(C:\Documents and 5eUings\regtien\Desktop\avYvavv4>prj} Help<br />
<br />
ËÏ*J ©:THINÖ <? ©:SYSTEM-CLASSA »-©:CLASSA ©•©:SLOTA »-©:FACETA ©"©:CONSTRA1NT* ©•©ANNOTATION* 9 ©Signaalgevers ©Tunnel-m atrixsignaalgevers 9 ©DynamischRoute Informatie Paneel ;Cj Matrixgedeelte ©Tekstgedeelte © Maatregel (SRegelscenario ©Actuator ©Sensor ©Tekstöericht<br />
<br />
il M Supordasses ©Qynamisch Route Informatie Paneel'<br />
<br />
Documentatlon Matnxgedeelle<br />
<br />
V C •+<br />
<br />
ConstFaffits<br />
<br />
-<br />
<br />
Een matrix van gelijk verdeelde pixels<br />
<br />
Role Concrete TemptoteStots Name SI Locatie SJ Kent_symbool SJKent_bericht SJUitzondering_handeling § Prioriteitenschema Sj Onderdeel_van_portaal<br />
<br />
Type Strins String Instance String Symbol String<br />
<br />
CardirïaUtv required single reguired multiple required multiple required single single single<br />
<br />
viëcim*-^<br />
<br />
Other Facets<br />
<br />
classes={Tekstbericht) al!owed-values={1,2.3)<br />
<br />
Nederlandse Organisatie voor toegepast-natuurwetenschappeiijk onderzoek / Netherlands Organisarion for Applied Scientific Research<br />
<br />
TNO TPD Memorandum<br />
<br />
Datum 28 juni 2002<br />
<br />
Bijlage G: schermafdruk van XML Schema in XML Spy<br />
<br />
Onze referentie I&I-MEM-020750 Blad 31<br />
<br />
entPhysicalTable entLogicalTable<br />
<br /> </div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="modal fade" id="report" tabindex="-1" role="dialog" aria-hidden="true">
<div class="modal-dialog">
<div class="modal-content">
<form role="form" method="post" action="https://adoc.pub/report/xml-data-definities-directoraat-ceneraa-rijkswaterstaat-advi" style="border: none;">
<div class="modal-header">
<button type="button" class="close" data-dismiss="modal" aria-hidden="true">×</button>
<h4 class="modal-title">Report "XML Data Definities. Directoraat-Ceneraa] Rijkswaterstaat. Adviesdienst Verkeer. Deelonderzoek Marktverkenning Componenten DVMsysteem"</h4>
</div>
<div class="modal-body">
<div class="form-group">
<label>Your name</label>
<input type="text" name="name" required="required" class="form-control" />
</div>
<div class="form-group">
<label>Email</label>
<input type="email" name="email" required="required" class="form-control" />
</div>
<div class="form-group">
<label>Reason</label>
<select name="reason" required="required" class="form-control">
<option value="">-Select Reason-</option>
<option value="pornographic" selected="selected">Pornographic</option>
<option value="defamatory">Defamatory</option>
<option value="illegal">Illegal/Unlawful</option>
<option value="spam">Spam</option>
<option value="others">Other Terms Of Service Violation</option>
<option value="copyright">File a copyright complaint</option>
</select>
</div>
<div class="form-group">
<label>Description</label>
<textarea name="description" required="required" rows="3" class="form-control" style="border: 1px solid #cccccc;"></textarea>
</div>
<div class="form-group">
<div style="display: inline-block;">
<div class="g-recaptcha" data-sitekey="6LcEnMcZAAAAAFHzKKgaE-Qh57XzUTzpfRElD4dP"></div>
</div>
</div>
<script src='https://www.google.com/recaptcha/api.js'></script>
</div>
<div class="modal-footer">
<button type="button" class="btn btn-default" data-dismiss="modal">Close</button>
<button type="submit" class="btn btn-primary">Send</button>
</div>
</form>
</div>
</div>
</div>
<script>
$(document).ready(function () {
var inner_height = $(window).innerHeight() - 250;
$('#pdfviewer').css({"height": inner_height + "px"});
});
</script>
<footer class="footer" style="margin-top: 60px;">
<div class="container-fluid">
Copyright © 2024 ADOC.PUB. All rights reserved.
<div class="pull-right">
<span><a href="https://adoc.pub/about">About Us</a></span> |
<span><a href="https://adoc.pub/privacy">Privacy Policy</a></span> |
<span><a href="https://adoc.pub/term">Terms of Service</a></span> |
<span><a href="https://adoc.pub/copyright">Copyright</a></span> |
<span><a href="https://adoc.pub/contact">Contact Us</a></span> |
<span><a href="https://adoc.pub/cookie_policy">Cookie Policy</a></span>
</div>
</div>
</footer>
<!-- Modal -->
<div class="modal fade" id="login" tabindex="-1" role="dialog" aria-labelledby="myModalLabel">
<div class="modal-dialog" role="document">
<div class="modal-content">
<div class="modal-header">
<button type="button" class="close" data-dismiss="modal" aria-label="Close" on="tap:login.close"><span aria-hidden="true">×</span></button>
<h4 class="modal-title" id="add-note-label">Sign In</h4>
</div>
<div class="modal-body">
<form action="https://adoc.pub/login" method="post">
<div class="form-group">
<label class="sr-only" for="email">Email</label>
<input class="form-input form-control" type="text" name="email" id="email" value="" placeholder="Email" />
</div>
<div class="form-group">
<label class="sr-only" for="password">Password</label>
<input class="form-input form-control" type="password" name="password" id="password" value="" placeholder="Password" />
</div>
<div class="form-group">
<div class="checkbox">
<label class="form-checkbox">
<input type="checkbox" name="remember" value="1" />
<i class="form-icon"></i> Remember me
</label>
<label class="pull-right"><a href="https://adoc.pub/forgot">Forgot password?</a></label>
</div>
</div>
<button class="btn btn-primary btn-block" type="submit">Sign In</button>
</form>
</div>
</div>
</div>
</div>
<!-- Global site tag (gtag.js) - Google Analytics -->
<script async src="https://www.googletagmanager.com/gtag/js?id=UA-177279549-1"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('config', 'UA-177279549-1');
</script>
<script src="https://adoc.pub/assets/js/jquery-ui.min.js"></script>
<link rel="stylesheet" href="https://adoc.pub/assets/css/jquery-ui.css">
<script>
$(function () {
$("#document_search").autocomplete({
source: function (request, response) {
$.ajax({
url: "https://adoc.pub/suggest",
dataType: "json",
data: {
term: request.term
},
success: function (data) {
response(data);
}
});
},
autoFill: true,
select: function( event, ui ) {
$(this).val(ui.item.value);
$(this).parents("form").submit();
}
});
});
</script>
<!-- cookie policy -->
<div id="ADOCPUB_cookie_box" style="z-index:99999; border-top: 1px solid #fefefe; background: #FFC107; width: 100%; position: fixed; padding: 5px 15px; text-align: center; left:0; bottom: 0;">
Our partners will collect data and use cookies for ad personalization and measurement. <a href="https://adoc.pub/cookie_policy" target="_blank">Learn how we and our ad partner Google, collect and use data</a>. <a href="#" class="btn btn-success" onclick="accept_ADOCPUB_cookie_box();return false;">Agree & close</a>
</div>
<script>
function accept_ADOCPUB_cookie_box() {
document.cookie = "ADOCPUB_cookie_box_viewed=1;max-age=15768000;path=/";
hide_ADOCPUB_cookie_box();
}
function hide_ADOCPUB_cookie_box() {
var cb = document.getElementById('ADOCPUB_cookie_box');
if (cb) {
cb.parentElement.removeChild(cb);
}
}
(function () {
var ADOCPUB_cookie_box_viewed = (function (name) {
var matches = document.cookie.match(new RegExp("(?:^|; )" + name.replace(/([\.$?*|{}\(\)\[\]\\\/\+^])/g, '\\$1') + "=([^;]*)"));
return matches ? decodeURIComponent(matches[1]) : undefined;
})('ADOCPUB_cookie_box_viewed');
if (ADOCPUB_cookie_box_viewed) {
hide_ADOCPUB_cookie_box();
}
})();
</script>
<!-- end cookie policy -->
</body>
</html>
<script data-cfasync="false" src="/cdn-cgi/scripts/5c5dd728/cloudflare-static/email-decode.min.js"></script> 
