| Author |
Message
|
| nikhilsharma |
 Posted: Wed Jul 15, 2009 11:07 pm Post subject: Difference b/w XMLNS and XMLNSC parser. |
 |
|
Apprentice
Joined: 10 Aug 2007
Posts: 28
|
Hi...
Please resolve the following query :
a) In Websphere Message Broker what is the difference between XMLNS and XMLNSC parser.
b) When should we use XMLNS and when XMLNSC.
Thanks With Regards
Nikhil
_________________
Nikhil |
|
| Back to top |
|
 |
| nvenkatesh |
| Posted: Wed Jul 15, 2009 11:44 pm Post subject: |
|
|
Apprentice
Joined: 29 Jan 2007
Posts: 45
|
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jul 16, 2009 8:48 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| You should use XMLNSC wherever you can. |
|
| Back to top |
|
|
| nikhilsharma |
| Posted: Thu Jul 16, 2009 10:19 am Post subject: |
|
|
Apprentice
Joined: 10 Aug 2007
Posts: 28
|
| mqjeff wrote: |
| You should use XMLNSC wherever you can. |
I agree...but one should have clear in his mind Where XMLNSC should be used and where XMLNS....just using anything unanimously won't clear the concept....am i right !!!!!!!!
_________________
Nikhil |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jul 16, 2009 11:48 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| nikhilsharma wrote: |
| am i right !!!!!!!! |
No. You should always use XMLNSC. There's no reason to use XMLNS (or even worse XML) any more.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kimbert |
| Posted: Sun Jul 19, 2009 2:06 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
The infocenter gives all the information that you need.
Use XMLNSC unless you can explain, with reference to the infocenter, why you need to use XMLNS. |
|
| Back to top |
|
|
| broker_new |
| Posted: Sun Jul 19, 2009 4:02 pm Post subject: |
|
|
Yatiri
Joined: 30 Nov 2006
Posts: 614
Location: Washington DC
|
it's better take out or disable the XML/ XMLNS parser option from the toolkit...
In that way you can by default impel us to rely on XMLNSC parser. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Sun Jul 19, 2009 9:57 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| broker_new wrote: |
it's better take out or disable the XML/ XMLNS parser option from the toolkit...
In that way you can by default impel us to rely on XMLNSC parser. |
Then how would we maintain existing flows?
If I were to change the parser from say XML to XMLNSC on a flow that was first developed for broker 2.0.1 back in 2002/3, it would have to go through a complete set of regression tests lasting 2-3 months (elapsed). The powers that be in this case would not be very happy.
_________________
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 |
|
|
| Vitor |
| Posted: Sun Jul 19, 2009 11:32 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| broker_new wrote: |
| it's better take out or disable the XML/ XMLNS parser option from the toolkit... |
Like many options there's that 0.01% chance you'll need to use XMLNS so the option should remain. Also (as my associate points out) there's a huge raft of existing flows that would need to be edited & tested if this sledgehammer is used to crack this nut.
Much easier to incorporate a check for these unwanted domains into the existing procuedures you use for QAing broker code. Because all your code is checked like this isn't it? 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jul 20, 2009 6:21 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| smdavies99 wrote: |
| broker_new wrote: |
it's better take out or disable the XML/ XMLNS parser option from the toolkit...
In that way you can by default impel us to rely on XMLNSC parser. |
Then how would we maintain existing flows?
If I were to change the parser from say XML to XMLNSC on a flow that was first developed for broker 2.0.1 back in 2002/3, it would have to go through a complete set of regression tests lasting 2-3 months (elapsed). The powers that be in this case would not be very happy. |
If that flow has remained substantially unchanged since it was first developed, there are almost certainly a fair to large number of business requirements that it is not meeting, because they have arisen since it was built seven years ago. So it almost certainly needs to be reexamined top to bottom, and rebuilt with additional functionality - which also requires regression testing lasting 2-3 months. |
|
| Back to top |
|
|
| broker_new |
| Posted: Mon Jul 20, 2009 7:27 am Post subject: |
|
|
Yatiri
Joined: 30 Nov 2006
Posts: 614
Location: Washington DC
|
What i really meant was as you migrate to the new version
any how you need to migrate the things to new version..
why don't you change the parser to XMLNSC as part of it? which can be included in the same testing with no additional cost.  |
|
| Back to top |
|
|
| Jimmy3 |
| Posted: Thu Aug 20, 2009 12:06 pm Post subject: |
|
|
Novice
Joined: 08 May 2007
Posts: 16
|
Ok, already there has been some debate whether or not we should include 'only' the XMLNSC parser, or the others as well, my definite answer would be yes - all the three.
This is out of practical experience I had whilst developing flows. Existing ,essages, which are really not namepace oriented or SOAP based have difficulties to be parsed with XMLNS. So we need the XML.
XMLNS, well ideally we should be using XMLNSC always, but some cases I have seen parser complains to work with a well formed message, that has namespace. Not sure of this reason though, but switching back to XMLNS makes it work! So we need all of them currently, and future years to come. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Aug 20, 2009 12:19 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Jimmy3 wrote: |
Ok, already there has been some debate whether or not we should include 'only' the XMLNSC parser, or the others as well, my definite answer would be yes - all the three.
This is out of practical experience I had whilst developing flows. Existing ,essages, which are really not namepace oriented or SOAP based have difficulties to be parsed with XMLNS. So we need the XML.
XMLNS, well ideally we should be using XMLNSC always, but some cases I have seen parser complains to work with a well formed message, that has namespace. Not sure of this reason though, but switching back to XMLNS makes it work! So we need all of them currently, and future years to come. |
No. XMLNSC is the only parser you should be deploying any flows with, unless as stated you can specifically point to something in the InfoCenter that says "XMLNSC can't parse this particular part of this particular message for this particular reason."
If you have unexplained errors with well-formed messages when using XMLNSC, then either your message is *not* well-formed or you need to open a PMR. |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Aug 20, 2009 3:00 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| This is out of practical experience I had whilst developing flows. Existing ,essages, which are really not namepace oriented or SOAP based have difficulties to be parsed with XMLNS. So we need the XML. |
Details please. What 'difficulties'?
| Quote: |
| XMLNS, well ideally we should be using XMLNSC always, but some cases I have seen parser complains to work with a well formed message, that has namespace. |
Same again. I would be *very* surprised if XMLNSC was rejecting a well-formed message. As mqjeff says, if you can prove it, you should raise a PMR. |
|
| Back to top |
|
|
| Mut1ey |
| Posted: Thu Aug 20, 2009 3:22 pm Post subject: |
|
|
Acolyte
Joined: 07 Oct 2005
Posts: 74
Location: England
|
| Quote: |
| Tip: If you require message tree to conform as closely as possible to the XML data model, perhaps because you are using certain XPath expressions to access the message tree, use the XMLNS domain. |
I would say that the above is one reason why you would use XMLNS over XMLNSC.
Just my 2peneth. |
|
| Back to top |
|
|
|
|
