StUF – patch download for version 2.04 (patch.bg0204.2009.04.22.zip)
Posted by jpluimers on 2009/05/05
Late last month, EGEM i-team released a patch for StUF 2.04 (Dutch link) that you can download.
There are a few fixes in it, for us, the most important one was a fix we already patched ourselves: the fact that the element kadestraleGemeentecode was not of type KadestraleGemeentecode, but of the wrong type Gemeentecode.
More on that below, but first an error that is in the new patch: the bg0204.wsdl has one include too much. You have to remove this one in order to make it work correctly:
<import namespace="http://www.egem.nl/StUF/StUF0204" location="..204\stuf0204.xsd"/>
Note that due to a bug in the WordPress parsing engine (it usually kills backslashes that are followed by a zero), you might not see the correct path above:
It needs to start as follows:
dot
dot
backslash
zero
two
zero
four
You have to remove this because of two reasons:
- the imported bgstuf0204.xsd already includes the stuf0204.xsd (you do not want double includes!)
- for compatibility reasons WSDL documents should not contain backslashes
Back to the changes, you will see the old fragment first, then the new fragment.
Fix for element kadestraleGemeentecode using the wrong type
Old fragment:
<element name="kadastraleGemeentecode" nillable="true" minOccurs="0"> <complexType> <simpleContent> <extension base="BG:Gemeentecode"> <attribute name="kerngegeven" type="boolean" fixed="true"/> <attribute name="gegevengroep" type="string" fixed="KDO1"/> <attributeGroup ref="StUF:element"/> </extension> </simpleContent> </complexType> </element>
New fragment:
<element name="kadastraleGemeentecode" nillable="true" minOccurs="0"> <complexType> <simpleContent> <extension base="BG:KadestraleGemeentecode"> <attribute name="kerngegeven" type="boolean" fixed="true"/> <attribute name="gegevengroep" type="string" fixed="KDO1"/> <attributeGroup ref="StUF:element"/> </extension> </simpleContent> </complexType> </element>
Reverting some enumeration types back to string types
In addition, they changed back some of the enumerations that a lot of legacy systems do not adhere to, for instance AcademischeTitelCode and AcademischeTitelOmschrijving back to regular strings again.
Old fragment:
<simpleType name="AcademischeTitelCode"> <restriction base="string"> <enumeration value="bc"/> <enumeration value="dr"/> <enumeration value="drs"/> <enumeration value="ing"/> <enumeration value="ir"/> <enumeration value="M"/> <enumeration value="mr"/> </restriction> </simpleType> <simpleType name="AcademischeTitelOmschrijving"> <restriction base="string"> <enumeration value="baccalaureus (titel voor HBO-opleiding niet resulterend in titel ing.)"/> <enumeration value="doctor (gepromoveerd of eredoctoraat)"/> <enumeration value="doctorandus (titel voor WO-opleiding niet resulterende in mr. of ir."/> <enumeration value="ingenieur HBO"/> <enumeration value="ingenieur WO"/> <enumeration value="master (eventueel gevolgd door een aanduiding waaruit de WO-opleiding blijkt)"/> <enumeration value="meester in de rechten WO"/> </restriction> </simpleType>
New fragment:
<simpleType name="AcademischeTitelCode"> <restriction base="string"> <maxLength value="10"/> </restriction> </simpleType> <simpleType name="AcademischeTitelOmschrijving"> <restriction base="string"> <maxLength value="200"/> </restriction> </simpleType>
More of these have changed, but I think you will grasp the idea.
Formalizing some implicit complexType definitions into explicit ones
Quite a few inline complexType definitions now are explicit, for example various instances of the a-nummer element have changed :
<element name="a-nummer" nillable="true" minOccurs="0"> <complexType> <simpleContent> <extension base="BG:A-nummer"> <attribute name="kerngegeven" type="boolean" fixed="true"/> <attributeGroup ref="StUF:element"/> </extension> </simpleContent> </complexType> </element>
into a typed element:
<element name="a-nummer" type="BG:A-nummer-e" nillable="true" minOccurs="0"/>
and one complexType:
<complexType name="A-nummer-e"> <simpleContent> <extension base="BG:A-nummer"> <attribute name="kerngegeven" type="boolean" fixed="true"/> <attributeGroup ref="StUF:element"/> </extension> </simpleContent> </complexType>
An extra XSD file is added, import/include are now mixed & the directory names changed
I’m not sure why this is the way it is done now, but the original release had thes XSD and WSDL files in this tree:
- stuf.0204\stuf0204.xsd
- stuf.bg.0204\bg0204.wsdl (imports bg0204.xsd and ../stuf. 0204/stuf0204.xsd)
- stuf.bg.0204\bg0204.xsd (imports ../stuf. 0204/stuf0204.xsd)
The new release has these files:
- 0204\stuf0204.xsd
- bg0204\bg0204.wsdl (imports bg0204.xsd and ../0204/stuf0204.xsd – actually this is done with backslashes)
- bg0204\bg0204.xsd (imports bgstuf0204.xsd)
- bg0204\bgstuf0204.xsd (includes ../0204/stuf0204.xsd)
So, the directory names have changed, it contains an extra file bgstuf0204.xsd, and an extra include is done (so one of the imports in the bg0204.wsdl must be removed, see above).
I know that in the XSD world it is practive to use includes for adding to the same namespace, and import to different namespaces, import can also be used for the namespace.
In this case, my toolset is .NET (more on that in a later blog post), and there the tools react distinctly different between import and include.
In addition, the change now causes the import of bg0204.wsdl to fail. So maybe the content of bgstuff0204.xsd could best have been added to the bg0204.xsd.
More errata in the Errata.0204.pdf document
There have been 20 RFC’s in total, of which almost 15 have been implemented so far.
You can read about those in the online download of the patch.
–jeroen
Guus Creuwels said
Hi Jeroen,
In the forum on the https://www.surfgroepen.nl/sites/stuf site the answer is that the patch on that website is the correct one. So I guess that’s what we need to use…
Kind regards,
Guus
jpluimers said
Thanks!
–jeroen
Guus Creuwels said
Hi Jeroen,
Somehow your download link (http://www.egem-iteams.nl/system/files/patch.bg0204.2009.04.22.zip) for the StUF patch gives another version than currently available from the Egem i-temas site: https://www.surfgroepen.nl/sites/stuf/Lists/Announcements/DispForm.aspx?ID=9.
I’m getting all confused now ;-)
Kind regards,
Guus
jpluimers said
Now this is food for some research :-)
Your link is the announcement page, and it ultimately points to this as download link: https://www.surfgroepen.nl/sites/stuf/Lists/Announcements/Attachments/9/patch.bg0204.2009.04.22.zip
My link is at the official egem site, and it ultimately points to this download link: http://www.egem-iteams.nl/system/files/patch.bg0204.2009.04.22.zip
The filenames are the same, but the content is different.
Actually, only one file in the content is different: bg0204.wsdl
In http://www.egem-iteams.nl/system/files/patch.bg0204.2009.04.22.zip, the bg0204.wsdl is older.
In https://www.surfgroepen.nl/sites/stuf/Lists/Announcements/Attachments/9/patch.bg0204.2009.04.22.zip, the bg0204.wsdl is newer.
The major differences between OLD and NEW:
OLD namespaces:
xmlns=”http://schemas.xmlsoap.org/wsdl/
xmlns:BG=”http://www.egem.nl/StUF/sector/bg/0204″
xmlns:StUF=”http://www.egem.nl/StUF/StUF0204″
xmlns:soap=”http://schemas.xmlsoap.org/wsdl/soap/”
xmlns:xs=”http://www.w3.org/2001/XMLSchema”
name=”StUFBG”
targetNamespace=”http://www.egem.nl/StUF/sector/bg/0204″
NEW namespaces:
xmlns=”http://schemas.xmlsoap.org/wsdl/”
xmlns:BG=”http://www.egem.nl/StUF/sector/bg/0204″
xmlns:StUF=”http://www.egem.nl/StUF/StUF0204″
xmlns:soap=”http://schemas.xmlsoap.org/wsdl/soap/”
xmlns:xs=”http://www.w3.org/2001/XMLSchema”
xmlns:ns=”http://www.egem.nl/StUF/StUF0204″
xmlns:tns=”http://www.egem.nl/StUF/wsdl/bg0204.wsdl”
name=”StUFBG”
targetNamespace=”http://www.egem.nl/StUF/wsdl/bg0204.wsdl”
The new wsdl way of importing namespaces now uses the Windows way of relative paths, which makes it harder to use on non-Windows systems.
The new wsdl has been last edited by someone of the ICTU foundation.
All changelog comments from the old wsdl have disappeared in the new wsdl.
In the body, all occurrences of BG: in the old wsdl have been replaced by tns: in the new wsdl.
Furthermore, in the body, all specific soapAction attributes in the old wsdl have been replaced by one generic soapAction (“http://www.egem.nl/StUF”) in the new wsdl (really odd!).
All in all, the new wsdl seems to rollback a few of the things that the old wsdl tried to accomplish:
– be WS-I compliant
– use a more generic namespace
– use unique soapActions for all operations
It looks like someone was NOT happy with that!
–jeroen
Guus Creuwels said
This is indeed reaaly Wiert ;-). I created a post in the StUF 2 Forum on the http://www.surfgroepen.nl/sites/stuf website. (https://www.surfgroepen.nl/sites/stuf/Lists/StUF%20301/Flat.aspx?RootFolder=%2fsites%2fstuf%2fLists%2fStUF%20301%2fwelke%20bestanden%20%28bg0204.wsdl%20en%20.xsd%27s%29&FolderCTID=0x012002002678BEF2E1AAB541B405F16FFCFCD46D)
jpluimers said
Wiert it is :-)
Thanks for posting on that forum.
You might want to include a link to this comment thread on that forum.
–jeroen