y On Tue, 20 Mar 2001, Brad O'Hearne wrote:
> This is a really interesting thread to me, because it really opens up a very > common business issue that I have been dealing with myself for the past year > and a half. This issue refers to the realities of implementation of xml as > a b2b information exchange method. It is hard enough to nail down a DTD (or > schema) that is satisfies parties on both sides, but in addition, it is > amazing to see what problems persist further even after that has been > established. Umesh's example is one of these. Personally, I have been > asked by business partners to do everything from allowing basically junk for > element content to satisy a DTD (so that the DTD is satisfied, but then I > have to sift through the data and provide some other parsing algorithm to > derive the actual content), to adding functionality to the parser that > invalidates the XML specification. > > <opinion> > While I understand that neither development nor the business end can take > place in a vacuum devoid of the presence of the other, (and in general, > let's be honest, the $$$ usually makes the decisions), from a technical > standpoint, I assess this struggle at the root is actually between realizing > the power of XML as an enforced, structured, communication contract between > parties and the desire to implement the same loosey-goosey way of doing > things in a new format. I have seen all matter of errors, problems, > barriers, etc. to both parties being able to implement, but it seems like > the common threads in all of them are three things: > > 1) Resistance to change. > 2) Resistance to really dissecting and understanding the business model. > 3) Resistance to responsibility for data integrity. > > While there are always good reasons for doing any number of unorthodox > things, my advice is to strive to preserve the integrity of the contract, > and responsibilities of the applications (or businesses, or parties, etc.) > on both sides. Otherwise, there is a good chance that down the road you > will have created a system that is very difficult to maintain, upgrade, etc. > Also, code (and projects) gravitate towards the lowest common denominator -- > and every compromise will end up being a fundamental feature of your system. > > One more directo piece of advice is if you are dealing with the prospect of > poor data integrity, rather than placing your efforts in some > mega-error-tolerant parsing mechanism, try to focus your efforts on helping > the data get created correctly. Keep the expectation of data integrity pure > on your side of the XML contract -- go over to the other side of the > contract to implement your error handling -- maybe create a client for your > biz - partners to feed data into or something like this -- it will keep your > internal system pure, and your partners will love you for it too... > </opinion> > > JMHO, sorry for the uncharacteristically "businessy" topic here -- but I bet > it is one that all of us implementors are living in. > > BradO > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Umesh > Subramanian > Sent: Tuesday, March 20, 2001 10:37 AM > To: [EMAIL PROTECTED] > Subject: Re: Validation of an XML against Schema > > > Wayne: > I take a more pessimistic view point, by not completely trusting the > sender of the XML . > From the standpoint of a service provider with an XML interface, I would > like all incoming messages to be validated before processing them. Even if > the client does not specify the schemaLocation (or worse, specifies a wrong > location), I would iike to intercept the message and validate it. So a > feature that allows us to associate a message that does not specify a > schemaLocation with a schema (or better yet a validator object - to avoid > the overhead of reading the schema file everytime) would be really useful > Thanks > -Umesh > > > > > Wayne Bradney wrote: > > No nerds around here - only geeks ;-)I've been considering the same > issues recently -- and I'm left curious as to why any system would want to > play around with the schema reference of an incoming document. If someone > sends you a document that references a particular schema, they're doing so > for very good reason, they're telling you that their document conforms to > that schema. Of course you can use the EntityResolver to point the way to a > locally cached version and avoid the network traffic, but in that case you'd > better be sure that the cached version is in sync with the referenced one. > On the other hand, if you get a document without a schema reference, that > may also be telling you something very important -- that the document does > not conform to any particular schema, and that you probably shouldn't > attempt to validate it at all.It's true that you're at the mercy of the > sending systems to get these things right, but I try to avoid making > assumptions about the documents I receive, and I never manipulate the schema > reference (if it doesn't validate as is -- it gets bounced back to the > sender). I'd be interested to get the group's views on how other systems > handle schema references.Regards, > Wayne M. Bradney > Wall Street Systems, Inc. > 30 Broad Street, 24th Floor > New York, NY 10004 > Phone: +1 (212) 401 8239 > E-Mail: [EMAIL PROTECTED] > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 20, 2001 11:25 AM > To: [EMAIL PROTECTED] > Subject: Validation of an XML against Schema > > I get XML documents from partners which we want to validate against > schema. > If they do specify any schema refernces thats fine I can use > MyEntityResolver to override resovleEntity and tell the parser to use the > schema based on the public and system ids But If they do not specify any > xsi:schemaLocation attribute then there is no way for my parser to validate > against a schema. > > i know there will be a hack developed by nerd. > > Thanks for your help > > -------------------------------------------------------------- > Tushar Dave > Employease Inc. > Phone: 404-495-5948 > Email: [EMAIL PROTECTED] > -------------------------------------------------------------- > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
