Typesafe XML parsing and validation












0















I have different XML file types which look something like this:



XML_A:



NODE_1
NODE_2


XML_B:



NODE_1
NODE_2
NODE_3


XML_C:



NODE_2
NODE_3


XML_D:



NODE_1
NODE_3


And also corresponding XSD schemes per each type and generated C# classes from them.



Now imaging i need to validate these nodes and compare their values with a database and with eachother (some kind of relationship validation).



Each node has it's own validator and it's same in all XML files (e.g. NODE_1 has same meaning everywhere, just like NODE_2, etc.).



Currently i validate everything with something like this:



public bool ValidateNode_1(XElement rootElement)
{
var node_1 = rootElement.XPathSelectElement("....");
//validation logic here
}


Since some node types are duplicated (e.g. NODE_1 in XML_A, XML_B, XML_D) there is one validator per node type.



The problem comes when the XMLs are updated (new version with nodes removed or changed their parent-child relationships).
It's not happening by surprise and i get all the new schemes and classes so i can prepare for that.
But validation is text based, so i need to update all the validators manually, adjusting node names and XPaths (and there are 100+ validators).



What i want is to use the generated C# classes for validation, so simple refactoring would work with renaming and compile time errors for changed relationships.
But since there are multiple types of XML files i can't just do like this:



public bool ValidateNode_1(NodeClass nodeClass)
{
var node_1 = nodeClass.NodeValue;
//validation logic here
}


Because there are multiple NodeClass classes defined for each XML type, even though they are identical.
They have no relation to eachother and reside in separate C# namespaces. Although namespace for XML and XSD is same.



So the question is, how to use generated C# classes for this kind of validation and not duplicate the validators per node type?



P.S.
XSD version is 1.0.










share|improve this question























  • Why are you validating "text based" and not by schema? The real problem is a lot of xml data is machine generated and you end up with a large number of descendants that do not match the data base tables which are flat. The solution is to parse the xml into flat tables that are structure the same as the database. Then do the comparison.

    – jdweng
    Nov 24 '18 at 14:36











  • Schema validation is the first step. Sorry i didn't mention that. But i can't use schema for node validation, since it requires some custom logic (not just "is this node allowed in database?"). And i'm not sure i understand how flatting will help here, since it also requires deserialization to multiple classes in multiple namespaces (the main problem i'm facing here), which leads to duplicating code per XML type.

    – Kasbolat Kumakhov
    Nov 25 '18 at 8:14
















0















I have different XML file types which look something like this:



XML_A:



NODE_1
NODE_2


XML_B:



NODE_1
NODE_2
NODE_3


XML_C:



NODE_2
NODE_3


XML_D:



NODE_1
NODE_3


And also corresponding XSD schemes per each type and generated C# classes from them.



Now imaging i need to validate these nodes and compare their values with a database and with eachother (some kind of relationship validation).



Each node has it's own validator and it's same in all XML files (e.g. NODE_1 has same meaning everywhere, just like NODE_2, etc.).



Currently i validate everything with something like this:



public bool ValidateNode_1(XElement rootElement)
{
var node_1 = rootElement.XPathSelectElement("....");
//validation logic here
}


Since some node types are duplicated (e.g. NODE_1 in XML_A, XML_B, XML_D) there is one validator per node type.



The problem comes when the XMLs are updated (new version with nodes removed or changed their parent-child relationships).
It's not happening by surprise and i get all the new schemes and classes so i can prepare for that.
But validation is text based, so i need to update all the validators manually, adjusting node names and XPaths (and there are 100+ validators).



What i want is to use the generated C# classes for validation, so simple refactoring would work with renaming and compile time errors for changed relationships.
But since there are multiple types of XML files i can't just do like this:



public bool ValidateNode_1(NodeClass nodeClass)
{
var node_1 = nodeClass.NodeValue;
//validation logic here
}


Because there are multiple NodeClass classes defined for each XML type, even though they are identical.
They have no relation to eachother and reside in separate C# namespaces. Although namespace for XML and XSD is same.



So the question is, how to use generated C# classes for this kind of validation and not duplicate the validators per node type?



P.S.
XSD version is 1.0.










share|improve this question























  • Why are you validating "text based" and not by schema? The real problem is a lot of xml data is machine generated and you end up with a large number of descendants that do not match the data base tables which are flat. The solution is to parse the xml into flat tables that are structure the same as the database. Then do the comparison.

    – jdweng
    Nov 24 '18 at 14:36











  • Schema validation is the first step. Sorry i didn't mention that. But i can't use schema for node validation, since it requires some custom logic (not just "is this node allowed in database?"). And i'm not sure i understand how flatting will help here, since it also requires deserialization to multiple classes in multiple namespaces (the main problem i'm facing here), which leads to duplicating code per XML type.

    – Kasbolat Kumakhov
    Nov 25 '18 at 8:14














0












0








0


1






I have different XML file types which look something like this:



XML_A:



NODE_1
NODE_2


XML_B:



NODE_1
NODE_2
NODE_3


XML_C:



NODE_2
NODE_3


XML_D:



NODE_1
NODE_3


And also corresponding XSD schemes per each type and generated C# classes from them.



Now imaging i need to validate these nodes and compare their values with a database and with eachother (some kind of relationship validation).



Each node has it's own validator and it's same in all XML files (e.g. NODE_1 has same meaning everywhere, just like NODE_2, etc.).



Currently i validate everything with something like this:



public bool ValidateNode_1(XElement rootElement)
{
var node_1 = rootElement.XPathSelectElement("....");
//validation logic here
}


Since some node types are duplicated (e.g. NODE_1 in XML_A, XML_B, XML_D) there is one validator per node type.



The problem comes when the XMLs are updated (new version with nodes removed or changed their parent-child relationships).
It's not happening by surprise and i get all the new schemes and classes so i can prepare for that.
But validation is text based, so i need to update all the validators manually, adjusting node names and XPaths (and there are 100+ validators).



What i want is to use the generated C# classes for validation, so simple refactoring would work with renaming and compile time errors for changed relationships.
But since there are multiple types of XML files i can't just do like this:



public bool ValidateNode_1(NodeClass nodeClass)
{
var node_1 = nodeClass.NodeValue;
//validation logic here
}


Because there are multiple NodeClass classes defined for each XML type, even though they are identical.
They have no relation to eachother and reside in separate C# namespaces. Although namespace for XML and XSD is same.



So the question is, how to use generated C# classes for this kind of validation and not duplicate the validators per node type?



P.S.
XSD version is 1.0.










share|improve this question














I have different XML file types which look something like this:



XML_A:



NODE_1
NODE_2


XML_B:



NODE_1
NODE_2
NODE_3


XML_C:



NODE_2
NODE_3


XML_D:



NODE_1
NODE_3


And also corresponding XSD schemes per each type and generated C# classes from them.



Now imaging i need to validate these nodes and compare their values with a database and with eachother (some kind of relationship validation).



Each node has it's own validator and it's same in all XML files (e.g. NODE_1 has same meaning everywhere, just like NODE_2, etc.).



Currently i validate everything with something like this:



public bool ValidateNode_1(XElement rootElement)
{
var node_1 = rootElement.XPathSelectElement("....");
//validation logic here
}


Since some node types are duplicated (e.g. NODE_1 in XML_A, XML_B, XML_D) there is one validator per node type.



The problem comes when the XMLs are updated (new version with nodes removed or changed their parent-child relationships).
It's not happening by surprise and i get all the new schemes and classes so i can prepare for that.
But validation is text based, so i need to update all the validators manually, adjusting node names and XPaths (and there are 100+ validators).



What i want is to use the generated C# classes for validation, so simple refactoring would work with renaming and compile time errors for changed relationships.
But since there are multiple types of XML files i can't just do like this:



public bool ValidateNode_1(NodeClass nodeClass)
{
var node_1 = nodeClass.NodeValue;
//validation logic here
}


Because there are multiple NodeClass classes defined for each XML type, even though they are identical.
They have no relation to eachother and reside in separate C# namespaces. Although namespace for XML and XSD is same.



So the question is, how to use generated C# classes for this kind of validation and not duplicate the validators per node type?



P.S.
XSD version is 1.0.







c# xml validation xsd xsd-1.0






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 24 '18 at 14:23









Kasbolat KumakhovKasbolat Kumakhov

489




489













  • Why are you validating "text based" and not by schema? The real problem is a lot of xml data is machine generated and you end up with a large number of descendants that do not match the data base tables which are flat. The solution is to parse the xml into flat tables that are structure the same as the database. Then do the comparison.

    – jdweng
    Nov 24 '18 at 14:36











  • Schema validation is the first step. Sorry i didn't mention that. But i can't use schema for node validation, since it requires some custom logic (not just "is this node allowed in database?"). And i'm not sure i understand how flatting will help here, since it also requires deserialization to multiple classes in multiple namespaces (the main problem i'm facing here), which leads to duplicating code per XML type.

    – Kasbolat Kumakhov
    Nov 25 '18 at 8:14



















  • Why are you validating "text based" and not by schema? The real problem is a lot of xml data is machine generated and you end up with a large number of descendants that do not match the data base tables which are flat. The solution is to parse the xml into flat tables that are structure the same as the database. Then do the comparison.

    – jdweng
    Nov 24 '18 at 14:36











  • Schema validation is the first step. Sorry i didn't mention that. But i can't use schema for node validation, since it requires some custom logic (not just "is this node allowed in database?"). And i'm not sure i understand how flatting will help here, since it also requires deserialization to multiple classes in multiple namespaces (the main problem i'm facing here), which leads to duplicating code per XML type.

    – Kasbolat Kumakhov
    Nov 25 '18 at 8:14

















Why are you validating "text based" and not by schema? The real problem is a lot of xml data is machine generated and you end up with a large number of descendants that do not match the data base tables which are flat. The solution is to parse the xml into flat tables that are structure the same as the database. Then do the comparison.

– jdweng
Nov 24 '18 at 14:36





Why are you validating "text based" and not by schema? The real problem is a lot of xml data is machine generated and you end up with a large number of descendants that do not match the data base tables which are flat. The solution is to parse the xml into flat tables that are structure the same as the database. Then do the comparison.

– jdweng
Nov 24 '18 at 14:36













Schema validation is the first step. Sorry i didn't mention that. But i can't use schema for node validation, since it requires some custom logic (not just "is this node allowed in database?"). And i'm not sure i understand how flatting will help here, since it also requires deserialization to multiple classes in multiple namespaces (the main problem i'm facing here), which leads to duplicating code per XML type.

– Kasbolat Kumakhov
Nov 25 '18 at 8:14





Schema validation is the first step. Sorry i didn't mention that. But i can't use schema for node validation, since it requires some custom logic (not just "is this node allowed in database?"). And i'm not sure i understand how flatting will help here, since it also requires deserialization to multiple classes in multiple namespaces (the main problem i'm facing here), which leads to duplicating code per XML type.

– Kasbolat Kumakhov
Nov 25 '18 at 8:14












0






active

oldest

votes











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53459126%2ftypesafe-xml-parsing-and-validation%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























0






active

oldest

votes








0






active

oldest

votes









active

oldest

votes






active

oldest

votes
















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53459126%2ftypesafe-xml-parsing-and-validation%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Wiesbaden

Marschland

Dieringhausen