|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
Validating XML via XSD specified via schemaLocation. |
« View previous topic :: View next topic » |
Author |
Message
|
Cogito-Ergo-Sum |
Posted: Thu May 09, 2013 9:28 am Post subject: Validating XML via XSD specified via schemaLocation. |
|
|
 Master
Joined: 07 Feb 2006 Posts: 293 Location: Bengaluru, India
|
I want a way to check if my XML document is valid against a schema. Problem is, the XSD will be different (actually, minor variations from a 'base' XSD). I can get the sender of XML documents to specify a XSD via schemaLocation in their document. I was thinking of passing this document to a Validation node to test the validity.
It didn't work.
I can see a statement in the ExceptionList to the effect 'Validation enabled but no message set provided'.
Is Validation node the right way to do this ? Does WMB XMLNSC parser 'download' the schema from schemaLocation ? Any suggestions how do I implement this ? _________________ ALL opinions are welcome.
-----------------------------
Debugging tip:When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth.
---Sherlock Holmes |
|
Back to top |
|
 |
mqjeff |
Posted: Thu May 09, 2013 9:34 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
Broker can't fetch schemas from remote locations.
They must be deployed to the broker. |
|
Back to top |
|
 |
goffinf |
Posted: Thu May 09, 2013 10:30 am Post subject: Re: Validating XML via XSD specified via schemaLocation. |
|
|
Chevalier
Joined: 05 Nov 2005 Posts: 401
|
Cogito-Ergo-Sum wrote: |
I can get the sender of XML documents to specify a XSD via schemaLocation in their document.
|
Talking personally, I find that approach to be somewhat flawed (apart from the fact that unless you write the code yourself, Broker can't dynamically load up a schema from the given relative or absolute location). Why flawed ?, well, *you* are really the arbiter of what is valid and what is not, not the caller. You even hint at it in your post ... ' the XSD might be different'
Of course you could take a different (aka: non XSD approach to business validation).
I'm just saying ...
Regards
Fraser. |
|
Back to top |
|
 |
mqjeff |
Posted: Thu May 09, 2013 10:34 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
secondarily, there's no guarantee that the sender will provide a schemaLocation that is a) valid, b) addressable from the public internet, c) addressable at the address given |
|
Back to top |
|
 |
Cogito-Ergo-Sum |
Posted: Thu May 09, 2013 7:37 pm Post subject: |
|
|
 Master
Joined: 07 Feb 2006 Posts: 293 Location: Bengaluru, India
|
mqjeff wrote: |
Broker can't fetch schemas from remote locations. |
For remote schemas, I would have tried something with XML catalogs, but, I am not sure if WMB would look up a catalog. Then again, I just found out that, even if the location was a file:/// URI, the validation does not happen.
Let me provide some background. More than validation, the aim is to determine completeness of the XML document. I need to work with an XML document whose elements are to be sourced from different sources at different times with no predictability†.
For example, I have a schema as complete.xsd which has imported schemas say, source_1.xsd, source_2.xsd, etc. I will have source_i.xsd and complete.xsd at a local repository. When I receive source_1.xml, I would validate it against complete.xsd. It will fail and I will persist source_1.xml. When source_2.xml comes in, I will 'merge' it with source_1.xml and validate against complete.xsd. This time, the validation might go through if the complete.xsd had only source_1.xsd and source_2.xsd.
It is expected that the chances of source_i.xml not validating against source_i.xsd to be very rare.
Perhaps, I could have a library that will have all such complete.xsd and deploy the same to broker. But, if a user wanted to add another complete.xsd, the solution would include deployment; something, I wanted to avoid.
†I am pushing for a mechanism to purge incomplete documents after a while. _________________ ALL opinions are welcome.
-----------------------------
Debugging tip:When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth.
---Sherlock Holmes |
|
Back to top |
|
 |
goffinf |
Posted: Thu May 09, 2013 10:38 pm Post subject: |
|
|
Chevalier
Joined: 05 Nov 2005 Posts: 401
|
You could create your own URIResolver and call it from Jave to retrieve your schemata I suppose. Seems like a bit of overkill though.
If you can run XSLT you could create a schematron implementation containing all of your completeness checks (this has the advantage that you would get an exhaustive list of all validation failures (and more usefully without the brittleness of complex XSDs ... something a recent poster on this list was after).
Or you could do the same in ESQL and perhaps couple that processing with transformation logic ?
Fraser. |
|
Back to top |
|
 |
mqjeff |
Posted: Fri May 10, 2013 5:19 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
You're trying to accomodate a lot of flexibility by writing code. It may be a better decision to reduce that flexibility through procedure and policy, rather than accomodate it through code.
What value is being achieved by allowing the sender of the document to specify the contract to use with the document?
How reliable is that contract?
What value is being derived by not forcing the sender to validate the document and instead defering the validation and completeness to the receiver?
This is really a process question - when Sender X produces a document, what role does Broker play? What responsibilities does that role require of Broker, and what responsibilities does it require of the sender?
Or are you trying to code defensively to protect yourself from broken organizational and operational management? |
|
Back to top |
|
 |
Cogito-Ergo-Sum |
Posted: Fri May 10, 2013 7:58 am Post subject: |
|
|
 Master
Joined: 07 Feb 2006 Posts: 293 Location: Bengaluru, India
|
mqjeff wrote: |
This is really a process question - when Sender X produces a document, what role does Broker play? |
Actually, it is not only about a given sender. This is about aggregating documents from Sender X, Sender Y, etc. and, all the while validating against a more 'encompassing' schema to determine, whether everything is available.
The constraints I have are:
A) There is no guarantee about the timing or even sequence between X, Y, etc. Although, the number of senders will be known and an 'encompassing schema', that covers the syntax/semantic of the sender documents, will be available.
B) There will be many such 'encompassing' schema to cover various combinations of different senders.
C) From a user's perspective, it should be no more than, "these are the senders and this is 'encompassing' schema."
I am able to do aggregation and was hoping to insert the schemaLocation in the aggregated document. The schemaLocation was pointing to the 'encompassing schema'; the name of which was pulled from a UserDefined Configurable service.
I hope, I am not sounding like, someone else has to do this work. I am just elaborating the requirement. _________________ ALL opinions are welcome.
-----------------------------
Debugging tip:When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth.
---Sherlock Holmes |
|
Back to top |
|
 |
mqjeff |
Posted: Fri May 10, 2013 11:46 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
Cogito-Ergo-Sum wrote: |
mqjeff wrote: |
This is really a process question - when Sender X produces a document, what role does Broker play? |
Actually, it is not only about a given sender. This is about aggregating documents from Sender X, Sender Y, etc. and, all the while validating against a more 'encompassing' schema to determine, whether everything is available.
The constraints I have are:
A) There is no guarantee about the timing or even sequence between X, Y, etc. Although, the number of senders will be known and an 'encompassing schema', that covers the syntax/semantic of the sender documents, will be available.
B) There will be many such 'encompassing' schema to cover various combinations of different senders.
C) From a user's perspective, it should be no more than, "these are the senders and this is 'encompassing' schema."
I am able to do aggregation and was hoping to insert the schemaLocation in the aggregated document. The schemaLocation was pointing to the 'encompassing schema'; the name of which was pulled from a UserDefined Configurable service. |
Ok. I follow all of that, and it makes sense. Except it doesn't make sense to solve the problem by creating a userdefined configurable service to point somewhere else to cause broker to go fetch the necessary schemas.
You should be able to just deploy all of the necessary schemas and then build and validate the aggregated message against the correct one.
So, why not do that? Particularly since the senders themselves aren't going to know about the schema that validates the aggregated document.
XMLNSC will pick the correct schema to use based on the root message tag.
Cogito-Ergo-Sum wrote: |
I hope, I am not sounding like, someone else has to do this work. I am just elaborating the requirement. |
No no. I'm just trying to understand why you're trying to solve this problme in this manner. |
|
Back to top |
|
 |
Cogito-Ergo-Sum |
Posted: Sun May 12, 2013 11:12 am Post subject: |
|
|
 Master
Joined: 07 Feb 2006 Posts: 293 Location: Bengaluru, India
|
mqjeff wrote: |
You should be able to just deploy all of the necessary schemas and then build and validate the aggregated message against the correct one.
|
I mentioned the same in a couple of posts above.
mqjeff wrote: |
So, why not do that? Particularly since the senders themselves aren't going to know about the schema that validates the aggregated document.
XMLNSC will pick the correct schema to use based on the root message tag.
|
From a user's perspective, there will be cases where, newer 'encompassing schemas' will be written. To use the newer schemea, a redeployment will be required; something I wanted to avoid. This is the reason behind this question. _________________ ALL opinions are welcome.
-----------------------------
Debugging tip:When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth.
---Sherlock Holmes |
|
Back to top |
|
 |
smdavies99 |
Posted: Sun May 12, 2013 12:08 pm Post subject: |
|
|
 Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
Cogito-Ergo-Sum wrote: |
From a user's perspective, there will be cases where, newer 'encompassing schemas' will be written. To use the newer schemea, a redeployment will be required; something I wanted to avoid. This is the reason behind this question. |
So what happens when these remote schemas get edited incorretly? You have absolutely no control over their contents. They might cause your whole flow to fall on its face just because the 3rd party got an edit wrong.
Frankly and IMHO, this is a disater waiting to happen. Get the schemas in-house and test the bejabbers out of them before they get anywhere near production.
If the 3rd party changes the data they are sending you then they have clearly broker the SLA and should be <redacted> until they promise not to do it ever again.
One system I'm woking on has a SLA of 10 minutes downtime a year. How long would it take for a level 3 support person to find the problem if the XSD's were remotely stored? _________________ WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
Back to top |
|
 |
mqjeff |
Posted: Mon May 13, 2013 8:54 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
Cogito-Ergo-Sum wrote: |
To use the newer schemea, a redeployment will be required; something I wanted to avoid. This is the reason behind this question. |
Why do you want to avoid a redeploy?
Because it's a production change that has to go through approvals?
As bruce says, any edit to these schemas is a production change.
Letting someone else do it, potentially badly, means that not only have you successfully avoided your own change management procedures, you've re-introduced the risk those procedures are designed to prevent in the first place. |
|
Back to top |
|
 |
|
|
 |
|
Page 1 of 1 |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|