XML serialize xsd alapján

.NET

Sziasztok!

Az elmúlt években nem egy XML feldolgozót írtunk meg .NET-ben úgy, hogy az xsd.exe-nek - ami a Microsoft SDK része - odaadtuk az xsd fájlt és ami generált belőle egy C# osztályt, amit a projektbe behivatkozva, pofon egyszerűen tudtunk XML-ekkel dolgozni.
Legutóbb XML feldolgozásnál az egyik nagy IT cég által publikált séma definíciókat használtuk. Az egy dolog, hogy roskadásig volt szintaktikai (hiányzó lezáró > karakterek) és szemantikai (adott node gyermek node-ja a lezáró tag-en kívül volt) hibákkal, felvettük a kapcsolatot a releváns csapattal és eddig a mi javaslataink alapján javították a séma definíciót. Azonban azt tapasztaltuk, hogy néhány XML-t nem tud feldolgozni a programunk, a deserialize metódus hívásakor kivétel keletkezik. Nosza, riportáltuk a hibát, mint eddig, viszont ezt már nem tudták reprodukálni. Küldtünk példa kódot, majd visszaigazolták, hogy látják a hibát és dolgoznak rajta. Három hét elteltével a következőt írták: “...However, this document (az xsd a szerk.) isn’t designed with the purpose of being able to develop .Net xml de-serialization based application. In instances like this typically an implementer comes up with alternative ways to achieve the objective. You may investigate direct xml parsing as a mechanism...”. Nekem valahogy úgy tűnik, hogy nem tudnak mit kezdeni a hibával, ezért próbálnak lebeszélni erről az irányról. Már rengeteg mindent kipróbáltunk, de eddig az xsd alapú feldolgozás tűnt az egyetlen működő megoldásnak. Van még, aki így dolgozik XML-ekkel és tapasztalt esetleg hasonló hibát?

( dotnetlinux | 2018. 05. 24., cs – 06:53 )

Nálunk évekóta megy, de egy tipikus esettel nem tud mit kezdeni: egy elemfajta egyszer szerepel csak benne, de mégis többes a kapcsolat. Szintaktikai hiba keletkezik valami ilyen helyen: "element[][] []". A generált kódot kézzel kell korrigálni és megy. Legalább a hiba determinisztikus.

Sajnos elképzelhető, hogy nem minden XSD-t tud kezelni, szerintem arra találták ki, hogy a TE általad publikált XSD-hez tudj könnyen kódot generálni. Addig módosítod az XSD-t, amíg kezelhető lesz. Sajnos.

Ha nem csak olvasod az XML-t, hanem írod is, akkor a cég módosíthgassa az XSD-t a könnyebb feldolgozhatóság miatt. (Ilyenkor szokott kiderülni, hogy ügyfelenként van külön-külön XSD és nem is omlik össze a rendszer, csak melózniuk kell vele).

( joco01 v | 2018. 05. 24., cs – 07:54 )

Nekem mindig működött az xsd.exe. Példakód nélkül nehéz ennél többet segíteni.

( ricpet | 2018. 05. 24., cs – 09:45 )

Az első kérdés: ha a hibát produkáló xml dokumentumot megpróbálod validálni az adott xsd-vel, akkor az sikeres lesz egyáltalán? (A leírtak alapján, pl. először hiányzó lezáró karakterek voltak stb. még ez sem tűnik biztosnak.)

Ha nem valid az xml az xsd alapján, akkor ezt lehet jelezni.

Ha valid az xml az xsd alapján, akkor jöhet az, hogy meg kell nézni konkrétan, mi az a részlet, amin elbukik. Azt tudni kell, hogy az xsd eléggé bonyolult, valamint akár eléggé laza szabályok leírására is ad lehetőséget, és egyáltalán nem biztos, hogy ezekre létezhet bármilyen automatizmus, ami ezt egy C# osztályhierarchiába értelmesen mappeli. Lehet, hogy itt bizony kézzel bizonyos dolgok deszerializálásáról gondoskodni. Érdemes megnézni az IXmlSerializable interfészt, amivel egy-egy osztály deszerializálását tudod kézzel szabályozni, és attól még a többi mehet automatikusan.

( penztar v | 2018. 05. 24., cs – 09:56 )

Hello!

A DataContractok között is érdemes körülnézni egy kicsit. Én anno sokat szivtam olyannal, ha egy-egy datamembernek object volt a típusa. Ezt nagyon nem szokta szeretni a deserializáló. És teljesen változatos és nem releváns exception-t lehet miatta kapni.

( persicsb | 2018. 05. 24., cs – 09:57 )

Maga az XSD valid amúgy? Szóval egy érvényes XML Schema leíró?

Nem feltétlen. Ha külön cég, simán mondhatják azt, hogy ők legyártották, nekik működik, szabványos, akkor ők minek szopjanak azért, ha valaki másnak a szarjával nem működik? (A .NET szerintem nem szar, ez egy képzeletbeli mondás :).) Ha egy cégen belül ilyen segítőkészek, akkor meg onnan menekülni kell tényleg.

Nem feltétlenül WTF mondat.
A lényege az, hogy ha esetleg bug lenne a .NET XSD -> C# kódban (előfordul, mint ahogy egy csomó minden másban is van, Javas XML feldolgozókban is), akkor nem a cég dolga úgy módosítani az XSD-t, hogy azt az xsd.exe megegye és ne bugos codepath-ra fusson.