[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: toxins/tocsins (was RE: XQueryandDTD/Schema?)
>If I use a conform XML parser I am unable to check that a document is a >valid SOAP document using a XML schema language or a XSLT >transformation. >In other words, I can't process a SOAP document with a conform XML >parser and a parser which processes a SOAP document as specified by the >SOAP specification isn't a conform parser, ie I need a different set of >tools to process XML and SOAP documents. Although I don't necessarily think the way SOAP is working makes it a good example of a way to build an xml application, it seems to me this is a case of setting up problems. Hmm, I know I've been accused of the same thing for my hatred of WXSDL(is that what we're calling it now)I mean that solutions can be built that process SOAP using the tools we are familiar with, the main thing seems to be the order by which one processes seems a little out of whack, and also fragile but only if you were expecting to receive xml that was non-valid SOAP. I mean that I can process SOAP as xml, the doing of this is however not fun and it might indeed be that I could run into cases where it was impossible for me to do what I wanted, in which case I would certainly change my tune from simply disliking SOAP and advocating REST-based principles wherever applicable, to refusing to deal with it and making fun of people that did(somewhat joking here). >> I seem to remember there was an early document concerning UBL where it >> was discussed having IDREFs being forward only, haven't looked at >> anything recently so unsure if that was adopted or not. This seems like >> another case of this thing, and it did not seem at the time anything in >> particular to worry about. >Shouldn't we worry to need a different set of tools for each new "XML >application"? >To me, that's the end of the interoperability between XML applications >and probably the end of XML too since for each application taken >separately there are always better solutions than XML! A forward only IDREF(to take the example above) would still function as an IDREF in an xml-processing application, if however you were going to generate|process|otherwise work with a language that used only forward looking IDREFs surely you would have to do some further constraints to achieve the results you wanted. I think however that these further constraints, although likely to be time-consuming and an irritation, could still be achieved with the tools one was familiar with. There are a lot of toolkits out there for working with different xml-derived languages, I scorn to learn most of them cause I see no point in learning a new tool to take the place of DOM|SAX|XSL-T for a particular language, even if processing that language is improved considerably.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|