>I meant at your end if your calling the service. >Its weird stuff and I have to admit I dont understand it very much. ...
> > But they become objects at the other end. Mainly structures. ... I'm not sure where this ended up. The top-posting may have confused things a bit. But here is some more info - hopefully not so basic that it insults anyone. First, XML is simply a "Text" type standard. Everything inside it is ASCII (well, that's an oversimplification - gotta look up a little about UTF-8, etc). When 'binary' data is included, tags like "CDATA" or data encoding (e.g. uuencode, base64binary, MIME, etc) are used. And, of course, since it's truly just simply text-based, the special characters used by XML itself (such as the "<" and ">") get "substituted" with other strings so the XML parser doesn't screw up. Next, the "construct" of XML is akin to a hierarchical DB model (think way back to the 1970s). So the concept of handling relationships of contained data are hierarchical. That works pretty well with things like customer->invoices->details. Not so well with in other cases. Now, "web services" will often send out XML "strings" as responses. If you have some good tools (most likely non-MS since MS doesn't want you to understand these things), you'll be able to capture those results to files and examine them directly. The text string will most likely not be the "pretty" XML you're used to seeing, but it can be reformatted easy enough (I think some tools will do that for you as well). Side bar: Early in XML days it was touted as a HUGE advancement because it made interfaces easy. Well, that was a bunch of BS. It did NOTHING to solve interface issues, it merely provided a layout approach that could describe interfaces. The main reason it caught on was that it was "new" and no one had a pre-existing advantage (e.g. EDI does things well, but there were many vendors that had their own proprietary approach to it, and attempted user-lock-in, etc). Also, when first demonstrated, the pretty indentation of it's hierarchical nature was shown. PHBs could actually understand it (probably because they were used to playing with Org charts) and immediately thought this meant computers could automatically understand any XML sent to it (which, of course, is blatantly untrue). Using XML has become pretty common, although really any text-based result-passing would work (yep, HTML, and even CSV if adhering to a binary-encoding agreement). But since XML caught on so widely, that is where most expect things to go (despite it's horrible bandwidth/processing consumption). And that is where the concept of WSDL came into being - which is basically just a description of the 'messages' and 'data' that a particular "web service" will provide. Of course, if you control both the source and destination, you're probably better off not using XML at all. But if you want to allow others to "hook into" your source, publishing WSDL information is expected. If you're reading from a source, you should be able to get their WSDL - if that source is truly embracing the overall XML concept. Reading an XML schema is not too bad, even if you've never looked at XML before. But for anything beyond very basic information you're going to need true definitions of the data content - something that gives true meaning to the elements (e.g. "start time" may not just be a time of day value, it may be number of seconds past an epoch, it may be how long it takes to initialize a device, etc). And I've found that opening an XML file using at pure text editor is actually very informative and useful (and I'm pleased to announce that MS hasn't screwed up Notepad, so even it is acceptable to use for such a task - so far). In many cases you'll be able to spot what the error is (if you understand XML basics) faster than a debugger. Of course, those mutli-megabyte XML files do get tiresome on the eyes... <g>. As Ed pointed out, going the MS-route will generally keep you in the dark. And, IMO, will most likely reduce the "elegance" of your solution - your target audience may get forced to Windows/MS-tools to use your service. E.g., MS just loves to throw a lot of their vendor-specific crap into their implementations so that only MS software can do special 'tricks' or other things to impress users. Just look at the old MS Frontpage (web page authoring) stuff. OMG, what a horrible mess of junk was in that - all specifically for Internet Explorer to play with. The same thing is happening with MS tools for XML. So, from a developer standpoint, you should really forego many of the higher level tools at first and get your hands dirty in the bowels of XML. The more you know about it, the better you'll be prepared to troubleshoot/optimize/etc. From an overall business standpoint, you should avoid MS tools due to the history of bastardizing standards, forcing upgrade costs to protect MS's revenue stream, and miscellaneous behind-the-scenes shenanigans (some quite illegal). But then, that's all common sense and has been discussed over and over. Some choose to live in the slop they're given, others try to get out of it. <shrug> -Charlie _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
