[
Lists Home |
Date Index |
Thread Index
]
>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.
|
