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-----Wayne:
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Umesh Subramanian
Sent: Tuesday, March 20, 2001 10:37 AM
To: [EMAIL PROTECTED]
Subject: Re: Validation of an XML against Schema
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]
--------------------------------------------------------------
