I think this is a little disingenuous. XML has its history in SGML, yes. However, the SGML standard (ISO 8879) was published in 1986. It's also true that SGML was originally based on GML. However, to claim that XML has "a history that extends back into the late 1960s" is really to claim that XML has a history in markup languages. Yep, and Java has a history in programming languages, which go back even further. ;-)
-- Martin Cooper ----- Original Message ----- From: "Dave Jarvis" <[EMAIL PROTECTED]> To: "Jakarta General List" <[EMAIL PROTECTED]> Sent: Saturday, November 17, 2001 11:07 AM Subject: Re: Business-Oriented XML > Hi, Jeff. > > > I'm with Jon here: Why the heck would you want to do this? > > See previous reply. In addition, languages come and go. Remember when > TurboPascal was hot? QuickBASIC? C and C++? Perl? PHP? What happens > in 5 years when another awesome language makes an appearance and > everyone forgets Java? Legacy code, I believe is the term. COBOL, > FORTRAN, Smalltalk, etc. Tying yourself to a language isn't a viable > long-term strategy. I love Java, don't get me wrong. But don't fool > yourself into thinking it's going to be around forever. ;-) (This > isn't flame bait; I'm using history and nearly 20 years development > experience as a guide.) XML, on the other hand, is a technology with > staying power and a history that extends back into the late 1960s! > > Another reason is that you can write more efficiently in a new > language. I've found that BOX source is typically 5 to 30 percent > smaller than equivalent Java. It has an extremely tight focus on basic > business logic. > > > for defining business logic. Why? It's trivial to define such logic in > > Java, and doing so avoids the limitations of your script (whatever they > > may be). > > The only limits are those imposed by the processing engine's > implementation language. (Currently Java, but could be C, C++, Perl, > etc.) > > Again, coupling yourself to Java (or any language for that matter) is > not a good thing from a long-term perspective. > > > What if you wanted to use a one-way hash on the passwords? What if user > > I had a similar problem already. The solution: > > <var name="hashKey" expr="generateHashKey( $parameter, $parameter2, > $parameter3 )"/> > > So long as "generatePasswordHash" is available to the system (neither > defined nor imposed), it'll work. > > > information was stored in EJBs or LDAP? What if you wanted to use the > > standard J2EE authentication and role-based security system? Can your > > script handle this? > > This can be solved in either of two ways: > > 1) Set up a small (internal) server that uses an XML-based protocol for > information exchange. > 2) Write a wrapper function to extract the information you want (e.g., > generateHashKey). > > > You can use whatever scheme you would like to test the password, limited > > only by your ability to express the behavior in Java. Furthermore, it > > <if test="!checkPassword( $password )"> > <var name="Phase" expr="'badPassword'"/> > <stop/> > </if> > > As before, not limited to a particular language. But you might as well > use Java, because Java rocks. :-) > > > this example, the yourHelper object). How would your system reuse > > business logic to build a Swing client? > > No -- but then again, that wasn't what it was designed to do. It is > meant for e-commerce/web-based solutions (plus interacting with remote > servers via XML, simple file I/O, and database laughter). Nearly all > e-commerce sites do the following: > > 1) Present HTML to the user. > 2) Gather information from the user. > 3) Do something with that information. > 4) Loop to Step 1. > > I'm under the impression that Cocoon is a bulldozer for such a trivial > scheme. BOX, keeping the analogy, would be a shovel: simple, > straightforward, precise, and almost intuitive. (The only truly > intuitive interface is the nipple.) > > I don't think this point can be stressed enough: BOX's design goal is to > solve the aforementioned 4-step process. It is tightly integrated with > XML, XSL, SQL, and file I/O -- to the intentional exclusion of all > else. It has minimal facilities required to run native code via > embedded function calls. GUI-based applications and batch processing > are beyond its ken: they would only serve to complicate the > architecture. > > BOX inherently knows about state transitions, broken down by Stages and > Phases. > > > And about the last point you brought up... how is your system any more > > platform, language, or database neutral than Struts, Maverick, Turbine, > > or WebWork? > > If the system is coupled with Java, you lose language independence. > When I say "language" I don't mean human languages. Just in case there > was some confusion. However, BOX is both programming language and human > language neutral. > > STRUTS > ------ > Struts is inextricably tied to Java. Struts also couples logic and > presentation (or can): > > <input type="text" name="username" value="<%= loginBean.getUsername() > %>"/> > > What if I wanted to limit the user names to a selection list? (Silly > example, but the idea can cause significant ripple effects; consider > typing in a catalogue name versus choosing one from a list, for those > who like practical examples.) > > Struts is big and bulky; another bulldozer. > > MAVERICK > -------- > Maverick is tied to Java. Also allows people to shoot themselves in the > foot with JSP. And if it's true that you can use XSL without XML, it > strikes me that you're losing a whole lot of control. (I couldn't find > much information on Maverick.) > > TURBINE > ------- > Turbine is coupled to Java. It's not easy to use any particular > database (e.g., an entire help section on how to integrate Oracle). > With BOX, you set the default database with a straightforward > configuration file: > JDBC_DRIVER=org.postgresql.driver.Driver > DB_URL=postgres://whatever:5432 > DB_USER=username > DB_PASS=password > -- > JDBC_DRIVER=com.oracle.driver.Driver > etc. > > Note that this is used by the processing engine. If you want to write a > processing engine in another language (like C++), then you have to > derive a mechanism to do the database connectivity. The business logic > never needs to know. Even better, you can add a DB_NAME property and > extend the BOX language thusly: > <sql name="'POSTGRESQL'"> > ... > </sql> > > This allows people to dynamically choose a different database during > runtime (note: completely backwards and forwards compatible; BOX is > extensible). > > Turbine, like Maverick, also lets you shoot yourself in the foot with > JSP. > > The control over the page layout strikes me as inflexible; or at the > very least quite complicated. With BOX, you are not limited to any > particular style or layout. For example, imagine a Help system embedded > within your main site. You want to give it a different header (and > footer). With BOX, simply alter the header included within the > presentation's XSL page: > > Regular header: <xsl:include > href="file://localhost/view/common/header.xsl"/> > Help header: <xsl:include href="file://view/common/help-header.xsl"/> > > WEBWORK > ------- > Lastly, there's WebWork. Tied to Java. (It incorrectly claims that > XML/XSLT isn't suitable for large scale application development. BOX > can handle hundreds of tables, tens of millions of rows for several > tables, for a system that has over 9000 clients, and over a million hits > a day. If that isn't a large enough scale, please hit me with the Clue > Stick.) > > WebWork also does the foot shooting thing with JSP. Server Pages (JSP, > ASP, PHP) will always scale incredibly POORLY because they couple > presentation and logic. There isn't a whole lot of information on > WebWork (example source, for example) on the SourceForge site. > > RED HERRING > ----------- > These projects keep touting the words "object-oriented" like some sort > of Golden Solution. If your e-commerce web site is nothing more than a > glorified state machine, why do you need the power of > object-orientation? To build a robust, extensible, and scalable > solution, use the key lessons OO teaches: > > o data encapsulation > o modularity > o code re-use > > As a side note, read up on the works of Alan Holub for a deep > understanding of "object-oriention". There's a related page on why > "get()" accessors are bad. The links follow: > > http://www.holub.com/ > http://joot.com/dave/writings/articles/encapsulation.html > > Conclusion > ---------- > In summary, BOX is an interpreted state machine. It completely > decouples presentation from logic, to the point that coupling them is > awkward (unlike ALL the other systems mentioned). The language syntax > is trivial (anyone who knows BASIC can learn BOX; there are about 20 > keywords), and extensible. Current technologies either roll you over > with complexity due to supplying everything, or constrain you in various > fashions (needs Java, needs JSP, forces presentation styles, etc.). BOX > is meant to be simple and impose as few restrictions as possible, while > giving the programmer complete control over what can happen insofar as a > web site is concerned. > > More database neutral? > Moreso than Turbine. As neutral as the others, yet BOX seems easier to > configure and maintain. > > More language neutral? > Definitely: it doesn't impose any Java requirements. > > More platform neutral? > Probably: it doesn't require Apache, Tomcat, Java, Xalan, or Xerces. > > Sincerely, > Dave Jarvis > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
