Beste mensen,
De volgende links bevatten relevante informatie voor de toepassing van MTOM/xop voor het verzenden van bijlagen:
http://www.w3.org/TR/soap12-mtom/ (specificatie van MTOM in combinatie met SOAP1.2)
http://www.w3.org/TR/xop10/ (specificatie van xop gebruikt door MTOM)
http://www.w3.org/Submission/soap11mtom10/ (specificatie van gebruik van MTOM in combinatie met SOAP1.1)
http://www.w3.org/TR/xml-media-types/ (specificatie van het specificeren van het MIME mediatype in het bericht en het schema)
http://weblogs.java.net/blog/2006/04/28/mtom-performance-jax-ws (Een grafiek van de performance van het verzenden van bijlagen met en zonder MTOM)
Mijn interpretatie van MTOM
MTOM is een protocolbinding die een alternatieve serialisatie beschrijft voor base64binary elementen in een bericht. MTOM schrijft niet voor dat de bijlage wordt aangeboden als een base64binary element. Het interface van de SOAP engine kan de bijlage in binaire vorm ontvangen en teruggeven zonder vertaling naar base64binary. MTOM biedt het meeste profijt, indien de bijlage binair wordt aangeboden. Het conceptuele model met een base64binary element is nodig om zaken als signing en encryption zonder problemen te laten functioneren op het SOAP-bericht.
Een en ander impliceert dat in schema een binair bestand wordt opgenomen als een element met base64binary als type.
Aandachtspunten
StUF bindt op dit moment aan SOAP1.1 en MTOM is gespecificeerd voor SOAP1.2. Voorstel is om binnen StUF vast te houden aan de SOAP1.1 binding en daarbinnen MTOM toe te passen conform de specificatie in http://www.w3.org/Submission/soap11mtom10/.
Ik wil alle leveranciers verzoeken om na te gaan of hun SOAP engine de binding van MTOM aan SOAP1.1 ondersteunt.
De JAXWS en de Axis2 implementatie van MTOM ondersteunen een parameter waarmee gespecificeerd kan worden dat MTOM niet gebruikt hoeft te worden voor binaries kleiner dan dan deze parameter. Het document http://weblogs.java.net/blog/2006/04/28/mtom-performance-jax-ws laat zien dat er voor kleine bijlagen geen performance penalty is. Ik stel daarom voor om binnen StUF voor te schrijven dat alle base64binary elementen in een bericht geserialiseerd dienen te worden via MTOM. Een en ander impliceert dat bijlagen alleen gecommuniceerd kunnen worden als zender en ontvanger beide MTOM ondersteunen. Voordeel van deze keuze is dat altijd duidelijk is hoe met binary data wordt omgegaan. Nadeel van deze keuze is dat binary data uitsluitend kan worden uitgewisseld tussen systemen die MTOM ondersteunen. Gaarne de mening van de leveranciers over deze keuze.
Het contenttype van een binaire bijlage kan gespecificeerd worden met behulp van een xmime:contentType attribute (zie http://www.w3.org/TR/xml-media-types/). Voorstel is om dit attribute optioneel op te nemen op een element met binary content. Er wordt gekozen voor optioneel, omdat alleen 'open' contenttypes gespecificeerd kunnen worden en contenttypes als MS Word e.d. niet.
De bestandsnaam is geen onderdeel van het RGBZ en de Dublin core. Omdat de bestandsnaam in de extensie zinvolle informatie bevat over de applicatie waarmee het binaire bestand verwerkt kan worden wordt voorgesteld om een attribute StUF:bestandsnaam verplicht (?) op te nemen op het element met binary content. Dit attribute dient in een apart schema dat de namespace StUF include gedefinieerd te worden. Bij gebruik van binaire bijlagen dient dit bestand met dit extra attribute gebruikt te worden. In de volgende versie van StUF wordt dit attribute opgenomen in de standaard zelf.
Voorstel
Het complexType voor een element met binary content wordt gedefinieerd in het schema waarin ook StUF:bestandsnaam wordt gedefinieerd:
<complexType name="BinaireInhoud" xmlns:xmime=http://www.w3.org/2005/05/xmlmime">
<simpleContent>
<extension base="xmime:base64binary">
<attribute ref="StUF:bestandsnaam" use="required"/>
</extension>
</simpleContent>
</complexType>
<attribute name="bestandsnaam" type=StUF:Bestandsnaam"/>
<simpleType name="Bestandsnaam">
<restriction base="string">
<maxLenght value="255"/>
</restriction>
</simpleType>
Alleen met het complexType BinaireInhoud mag een element met base64binary-inhoud in een StUF-bericht worden opgenomen.
Over MTOM heb ik niets in te brengen, ontbeer de daarvoor noodakelijke kennis. Aangezien dit aansluit bij landelijke standaarden (OSB) lijkt me dit een goede keuze.
Ten aanzien van het contentType-attribute, als ik dit zo lees komt dit overeen met het RGBZ-attribuut enkelvoudigDocument.documenformaat. Dit kent een kardinaliteit van 1-1 oftewel verplicht te vullen. Het verbaast me dan ook dat het contentType-attribute optioneel is. Hoe weet je dan wat voor een soort documentbestand het is?
Tot slot de voorgestelde bestandsnaam. Deze komt bewust in het RGBZ niet voor. Elke document kent een aantal identificerende attributen. Primair en uniek uiteraard de document-identificatie. Verder ook de documenttitel. Een bestandsnaam voegt m.i. niets toe. Het is in de praktijk niet meer dan de naam waaronder een individuele partij een document vastlegt. Dit kan tussen partijen verschillen, bijvoorbeeld vanwege persoonlijke voorkeur of naamgevingsconventies. Dat willen we dus niet met elkaar delen. Het is ook niet nodig. Genoemde identificerende kenmerken zijn voldoende. Belangrijk in dit kader is dat ook de Dublin Core dit attribuut niet kent. En ook in de MOREQ en de NEN heb ik 'm niet kunnen vinden. Genoemde identificerende kenmerken i.c.m. met het eerder genoemde attribuut documentformaat (ook een DublinCore-attribuut) maken het voor iedere partij mogelijk desgewenst een fysieke bestandsnaam toe te kennen cq. te genereren, inclusief de extensie tbv. het soort documentbestand.
Conclusie mijnerzijds: bestandsnaam voegt niets toe, is niet nodig en willen we niet met elkaar delen. Niet toevoegen dus.