WebHU - Programozási kérdések és válaszok

Hogyan lehet javítani az XSD-ellenőrzés bőbeszédűségét

Különféle xsd-ellenőrzési típusokat fedeztem fel a XmlDocument.Validate(ValidationEventHandler), XDocument.Validate(schemas, ValidationEventHandler) és XmlReader használatával, egy olyan sémával, amely egy ValidationEventHandler visszahívásra küldi az eredményeket.

A visszahívás azonban gyakorlatilag csak a súlyosságot és a hibaüzenetet adja meg. Ilyen üzeneteket kapok:

The 'name' attribute is invalid - The value '' is invalid according to
its datatype 'TNonEmptyStringNoWhitespacesAtBeginningAndEnd' - The
Pattern constraint failed.

Most messze nem ideális hibaüzenetek. A visszahívási paraméterek nem adják meg, hogy ezt melyik szülő okozta, sem azt, hogy milyen XML-sorról van szó, sem semmi praktikus dolgot.

Az én forgatókönyvemben nem minden név a fenti típusú, némelyik egyszerűen üres karakterlánc lehet (mivel nem kötelező).

Most, hogy valószínűleg több száz névvel rendelkező xml-csomópont van, nagyon bosszantó a fenti probléma felkutatása, mivel nincs környezeti információ a helyről, még az sem, hogy mi az xml-csomópont.

Hogyan lehet kiterjeszteni egy ilyen érvényesítés bőbeszédűségét? A Notepad++ például egy XML Tools beépülő modult használ, amely a fenti üzenetet a következőképpen adja ki:

Az aktuális fájl érvényesítése XML-séma használatával:

ERROR: Element 'LightSource', attribute 'name': [facet 'minLength'] The value '' has a length of '0'; this underruns the allowed minimum length of '1'.
ERROR: Element 'LightSource', attribute 'name': [facet 'pattern'] The value '' is not accepted by the pattern '.*\S'.
ERROR: Element 'LightSource', attribute 'name': '' is not a valid value of the atomic type 'TNonEmptyStringNoWhitespacesAtBeginningAndEnd'.

Ez bőbeszédű, és legalább néhány kontextus-információt jelez, például a probléma egy LightSource elemen jelenik meg, és hogy pontosan mi hibázott a mögöttes típussal.

Vannak más lehetőségek, amelyek lehetővé teszik a megfelelő C# XSD érvényesítést megnövelt környezeti információkkal?

Az érvényesítések az XML memórián belüli megjelenítésén történtek XDocument és XmlDocument szempontjából, valamint a XmlReader fájlból olvasva. Nyilvánvalóan a sorszámoknak stb. csak olyan kontextusban lenne értelme, ahol egy xml fájl már meg van írva, de más információk, mint például a szülőelem stb., hasznosak lennének, így legalább az xml-környezetet kiadhatnám, ahol megnézhetem.


A teljesség kedvéért néhány kód:

    var schemas = new XmlSchemaSet();
    schemas.Add("", xsdPath);
    var doc = XDocument.Load(xmlFile);
    doc.Validate(schemas,ValidationEventHandler);

    public void ValidationEventHandler(object sender, ValidationEventArgs e)
    {
        // Not much in e
        switch (e.Severity)
        {
            case XmlSeverityType.Error:
                Console.WriteLine("Error: {0}", e.Message);
                break;
            case XmlSeverityType.Warning:
                Console.WriteLine("Warning {0}", e.Message);
                break;
        }

    }

Egy másik ígéretesnek tűnő próbálkozás a http://msdn.microsoft.com/en-us/library/as3tta56%28v=vs.110%29.aspx, de egyáltalán nem növelte a bőbeszédűséget.


Néhány magyarázat a fennmaradó részhez.

Van néhány típusom, amely korlátozást képez:

<xs:simpleType name="TNonEmptyStringNoWhitespacesAtBeginn">
    <xs:restriction base="xs:string">
        <xs:pattern value="\S.*" /> 
        <xs:minLength value="1"/>
    </xs:restriction>
</xs:simpleType>

<xs:simpleType name="TNonEmptyStringNoWhitespacesAtBeginningAndEnd">
    <xs:restriction base="TNonEmptyStringNoWhitespacesAtBeginn">
        <xs:pattern value=".*\S" />
        <xs:minLength value="1"/>
    </xs:restriction>
</xs:simpleType>

Hagyja figyelmen kívül a TNonEmptyStringNoWhitespacesAtBeginn, amely segít az ÉS-korlátozások engedélyezéséhez. Tehát ha van egy name attribútum a fenti típussal, amely csak egy üres karakterlánc, nagyon eltérő mennyiségű információt kapok a C#s XSD érvényesítéséből és abból, amit a Notepads++ XML Tools Plugin csinál. Íme a különböző üzenetek a teljesség kedvéért:

C#

The 'name' attribute is invalid - The value '' is invalid according to
its datatype 'TNonEmptyStringNoWhitespacesAtBeginningAndEnd' - The
Pattern constraint failed.

Jegyzettömb++

ERROR: Element 'LightSource', attribute 'name': [facet 'minLength'] The value '' has a length of '0'; this underruns the allowed minimum length of '1'.
ERROR: Element 'LightSource', attribute 'name': [facet 'pattern'] The value '' is not accepted by the pattern '.*\S'.
ERROR: Element 'LightSource', attribute 'name': '' is not a valid value of the atomic type 'TNonEmptyStringNoWhitespacesAtBeginningAndEnd'.

A kivételtartalom által biztosított információkkal lekérhetem és megjeleníthetem az XML-elemet, de azt mondani, hogy a TNonEmptyStringNoWhitespacesAtBeginningAndEnd megszorítása sikertelen, sokkal kevésbé kifejező, mintha azt mondanám, hogy a részletek melyik része hibásodott meg. Tudom, hogy értem a tippet, hogy a minta megszorítása meghiúsult, de bárkinek, aki ilyen üzenetet kap, meg kell találnia a típust, és meg kell vizsgálnia a megszorításait, hogy megismerje a kényszert. Ha megvizsgáljuk a kivétel adatait, úgy tűnik, ez itt a részletezési szint.

Úgy tűnik, hogy az XML Tools Plugin képes minden egyes érvényesítési elemet sokkal részletesebben megjeleníteni. Ez nem csak az XSD-ből következtethető, inkább úgy néz ki, mint az egyes megszorítások feldolgozási lépései által nyert információ.

Amit reméltem, az az volt, hogy növeljem az érvényesítő szóhasználatát, hogy több információhoz jussak.

15.01.2014

Válaszok:


1

Re: sorszámok... XDocument esetén, ha engedélyezi a sorinformáció rögzítését

XDocument xdoc = XDocument.Load(reader, LoadOptions.PreserveWhitespace | LoadOptions.SetLineInfo | LoadOptions.SetBaseUri);

akkor az érvényesítéskezelő kivonja ezt a valami ehhez hasonlót a közzétett ValidationEventHandlercode-ból (IXmlLineInfo):

IXmlLineInfo node = sender as IXmlLineInfo;
if (node != null && node.HasLineInfo()) ...

Ennek le kell fednie a kívánt információkat...

Hagyományos DOM esetén lehetősége van a Kivétel tulajdonság (a LineNumber és LinePosition), legalábbis elméletileg az Exception tulajdonságon keresztül a SchemaObjectProperty. Minden kódomban XDocumentet használok, és ez biztosan jól működik.

Ennek el kell kezdenie, hogy legalább jobb helyet biztosítson a vonal/pozíció tekintetében (ami akkor is működne, ha a memóriában van).

(Frissítések módosított kérdés alapján)

A C# nem adja meg azt, amit az általad hivatkozott bővítménynél lát... számomra ez egy megvalósítási választás. Az XSD aspektusok együtt működnek; ezért minden kudarc érvénytelennek tekinti az egészet.

A .NET beépített XSD-ellenőrzője általános cél, túl sok ellenőrzési módosítás nélkül (az egyetlen megoldás az, hogy egyedi részecske-attribúciót kell tenni vagy sem). A teljesítmény kiegyensúlyozása érdekében a fentiek megtörténnek az egyszerű típusellenőrzéseknél.

Úgy tűnik, hogy a beépülő modult interaktivitásra tervezték... úgy tűnik, a lehető legtöbbet akarja elmondani, függetlenül attól, hogy mire van szüksége...

15.01.2014
  • Ez rendkívül kielégítő. Köszönöm. Ellenőriztem a sorok pozícióját és a számokat az első futtatásomon, de ezt egy frissen létrehozott in-memory-dom objektumon tettem, és nyilvánvalóan nem volt sor információ. Az IXmlLineInfo valóban segít nekem. 15.01.2014
  • Az imént jöttem rá, hogy még mindig nyitott a kérdés, hogy kaphatok-e mélyebb magyarázatot a megszorítások megsértésére abból a szempontból, hogy egy megszorítás mely része nem sikerült. 24.01.2014
  • @Samuel, ez az utolsó darab... nincs benne a kérdésben, és nem egyértelmű a megjegyzésed sem, hogy mit értesz alatta. Ha a megszorítás melyik része nem sikerült, akkor a kivételt okozó XSD-komponensre gondolt... akkor megpróbálhatja megvizsgálni a kivételben szereplő SchemaObject-et. Nem tudok azonban olyan XSD-tudatos processzorról, amely sorszámmal/pozícióval jelezné azt az adott aspektust (felsorolás, hossz, maxLength stb.), amelyik meghibásodott... a kivételben szereplő üzenet általában segít annak jelzésében, hogy mi nem sikerült. .. 24.01.2014
  • Elnézést, hogy itt nem egyértelmű. A pontosítás érdekében módosítottam a bejegyzésemet. 24.01.2014
  • Új anyagok

    A rádiógomb ellenőrzött eseményének használata a jQueryben
    Ebben a cikkben látni fogjuk, hogyan kell dolgozni a jquery választógombbal ellenőrzött eseményeivel. A választógombok HTML gombok, amelyek segítenek kiválasztani egyetlen értéket egy csoportból...

    Körkörös függőségek megoldása terraformban adatforrásokkal – lépésről lépésre
    Mi az a körkörös függőségek Dolgozzunk egy egyszerű eseten, amikor az SQS-sor és az S3-vödör közötti körkörös függőség problémája van egy egymástól függő címkeérték miatt. provider..

    Miért érdemes elkezdeni a kódolást 2023-ban?
    01100011 01101111 01100100 01100101 — beep boop beep boop Világunk folyamatosan fejlődik a technológia körül, és naponta fejlesztenek új technológiákat a valós problémák megoldására. Amint..

    🎙 Random Noise #2  – Örökbefogadás és hit
    az analitika íratlan világának gondozása Szeretné, hogy ezek a frissítések a postaládájába kerüljenek? Iratkozzon fel itt . "Ha önvezető autókat gyártanak, akkor mi miért ne..

    A legrosszabb politika és prediktív modellek májátültetésre jelöltek számára az Egyesült Államokban
    A máj (vagy óangolul lifer) az emberi test legnehezebb belső szervére utal, amely csendesen működik a nap 24 órájában. Mit csinál a máj? 500 feladatot hajt végre a szervezet egészségének..

    5 webhely, amely 2022-ben fejleszti front-end fejlesztői készségeit
    Frontendmentor.io A tényleges projektek létrehozásával a Frontendmentor.io segítséget nyújt a front-end kódolási képességeinek fejlesztésében. A kódolást azután kezdheti meg, hogy..

    Mikor kell használni a Type-t az interfészhez képest a TypeScriptben?
    A TypeScript a JavaScript gépelt szuperkészlete, amely statikus gépelést ad a nyelvhez. Ez megkönnyíti a robusztus és karbantartható kód írását azáltal, hogy a hibákat a fordítási időben..