[Home] [By Thread] [By Date] [Recent Entries]
Patrick, But that is the rub here, is it more complicated? Frankly schema works for tiny small schemas with few if any logical branches to the structure - but even there you run into difficulties - e.g. stock quote lookup, how tough is that? Put in stock ticker symbol - get back quote. Hmmm, but then the ticker is related to exchange, and status of the company, so could have prefix with colon separator, and so on - suddenly a tiny little something - and schema really cannot provide enough validation already. Unless you add more fields, and have prefix, exchange, ticker, name, but now you need rules - if I enter name and exchange, but not prefix and ticker.... how can I use schema to check the right permutations for me? But wait, I can declare varients of just the permutations of structure that I want and label them accordingly. Now I need a way for people to know what context to use what structure construct. Oh - how I do that? (hint - you need context variables). Then as soon as you get into significant information exchanges with dozens of inter-related fields - oh my! Schema really does have a very limited use profile. That is the way it was defined of course - they did start with a set of requirements. Trouble is few if any people who are using schema have bothered to read what the original design was intended to do. 9 times out of 10 it ain't what people are now trying to use schema for! No surprises then that it is sub-optimal for their needs. DW. Quoting Patrick Yee <kcyee@c...>: > On top of Schema checking, an even upper layer may offer checking of > semantics, too. This is, IMHO, a new concept which does not appear in > the TCP/IP stack. Needless to say, it is more complicated than Schema > checking. > Regards, -Patrick > > > Jimmy Zhang wrote: > > >IP packets are much simpler to check because the head > >fields are fixed in length. CRC checking is typical, > >and is equvalent to signature of SOAP. > > > >Other checking, such as IP, port, process id, TCP flow > >control etc, are less sophiscated than Schema. > > > >Deep content inspection offers to look at teh packet > >content,but still is less complicated than Schema. > > > >--- costello@m... wrote: > > > > > > > >>Hi Folks, > >> > >>I remember reading a long time ago a posting by > >>David Megginson. Paraphrasing, David said, "when > >>dealing with XML you are working down at the bare > >>metal". > >> > >>Other technologies work down at the bare metal, such > >>as TCP/IP. Perhaps there are lessons to be learned > >>there? Certain TCP/IP packets are rejected as bad > >>and the other packets are accepted and passed up to > >>other layers, where those layers perform additional > >>constraint checking. > >> > >>If we accept the conjecture that XML is down at the > >>bare metal level, then perhaps the only constraint > >>checking that should be done by an XML Schema is > >>parallel to the kinds of checking that is done on > >>TCP/IP packets. All other constraint checking is > >>passed up to other layers. > >> > >>Can someone characterize the kind of constraint > >>checking that is done on TCP/IP packets? What would > >>be the parallel constraint checking in XML Schemas? > >>/Roger > >> > >> > >> > >> > >> > >> > >> > >----------------------------------------------------------------- > > > > > >>The xml-dev list is sponsored by XML.org > >><http://www.xml.org>, an > >>initiative of OASIS <http://www.oasis-open.org> > >> > >>The list archives are at > >>http://lists.xml.org/archives/xml-dev/ > >> > >>To subscribe or unsubscribe from this list use the > >>subscription > >>manager: > >><http://www.oasis-open.org/mlmanage/index.php> > >> > >> > >> > >> > > > > > >----------------------------------------------------------------- > >The xml-dev list is sponsored by XML.org <http://www.xml.org>, an > >initiative of OASIS <http://www.oasis-open.org> > > > >The list archives are at http://lists.xml.org/archives/xml-dev/ > > > >To subscribe or unsubscribe from this list use the subscription > >manager: <http://www.oasis-open.org/mlmanage/index.php> > > > > > > > > > ----------------------------------------------------------------- > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an > initiative of OASIS <http://www.oasis-open.org> > > The list archives are at http://lists.xml.org/archives/xml-dev/ > > To subscribe or unsubscribe from this list use the subscription > manager: <http://www.oasis-open.org/mlmanage/index.php> > >
|

Cart



