[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: COMPLEXITY BIG ISSUE
Message text written by Rob Weltman > Think of a SAX parser as a compiler. You need a compiler to turn source into executables, and you need a SAX parser (or something comparable) if you are processing XML in a streaming way. The SAX spec allows you to choose your parser from any compatible provider (Sun, IBM, Apache), much as a language spec allows you to choose a compiler from various vendors. The Apache provider now supports XML Schema, and I expect the others to do so as well. You can use Apache for development now, and Sun or IBM later, if you want to. SAX is very, very widely deployed - hardly something waiting for a use. Rob <<<<<<<<<<<<<<<< Rob - I say again - this is a programmer centric view of the world. I look at that Apache stuff - I understand it - and I know SAX. I still say - 'for what?'. Given the use domain of Apache I could see someone saying something like: OK - lets implement server side includes using XML for both DOM and SAX. This will allow us to have resolved business objects as content. Or, lets implement support for an XML mechanism to request/respond certain parameters out of the Apache server environment. Now if I go back get these two running - go over to the Web site you quoted, I'll see all this - and I can have concrete idea of what/where/how. Enhanced functionality. I also get a sense of going forward - that if I implement this - it will be enhanced and supported. Right now - all you have is a testbed - with no focus. Thanks, DW.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC