RE: Tables, Wrappers and MLs, oh my! -- JAVA400-L


Brad Stone wrote:

>So, basically what I did was create a table object that accepts
information
>to query any DB on our network (actually, anyone it can get to with the
JDBC
>drivers I have installed).

>It then returns the data in a table, with which I can do anything I want
to.
>And it will return the data in any format (xML) that I want.

And, it seems to have been a great discussion, though I didn't follow every
twist and turn of the 'plot.'

My biggest criticism, which my specific example would have made more
obvious, is that XML and HTML are really very different.  XML is not just a
respelling of HTML -- it has a different purpose.  As will be seen, the
current discussion can still apply unchanged, despite this, but it is not
certain to be true.

I am not the world's greatest XML expert, but read on as I think what
follows is pretty conventional wisdom about XML and also a related
discussion about heaps.

One thing that RPG-trained programmers are unaccustomed to is heap storage.
In Java terms, a network of objects linked together.  Perhaps RPG IV
programmers have more familiarity with this, but Java readily permits much
larger and more sophisticated arrangements between objects at run time than
even RPG IV.  For instance, an HTML document could be represented, at run
time, by individual rows, one by one, or one could for some reason build up
the entire HTML document as a "root" object and connect everything together
with object references.

This last idea may well seem strange and it is for HTML.  Why?  Because the
HTML has no real affinity for the actual underlying data.  It is really, in
the end, "pretty print".  However, for XML this sort of
root-and-entire-object approach can make sense.  In fact, the XML interface
set allows both approaches in the standard IBM XML4J definition implements
of something called DOM (whole tree) and SAX (individual pieces). This is
no accident.

This is all somewhat independent of the O-O discussion, so it may not be
something to tackle at all or at least until the original discussion ends.

Now, if one is simply exporting HTML or XML and neither has any effect on
the core application, then this distinction is academic and the entire
existing discussion is just fine.

However, if there is an existing network of objects (say, what would be a
sequence of related relational data base records like an entire "order",
summary and detail records) all created and linked together at run time,
the question of HTML versus XML could become more acute.  Why?  Because the
XML form would have much more semantic agreement with the existing network
of objects or DB2 records.  It might even be the case that the existing
Java code might convert to make the original object network essentially
"be" the XML tree.  The practicality of this would vary and might relate to
issues like "the existing internal logic of the application family" versus
"a standard industry XML model or model(s) that one must export to."

With all this, exporting to HTML might still be an issue; one might still
need to produce web output all independent of using XML to deliver orders
to one's supply chain, for instance.

The specifics could potentially reduce the level of agreement in the
various "decorator" classes or it could simply change the structure of it a
bit and leave it logically unchanged (reducing the arguments as I suggested
last time).  That's what an actual example would help illustrate.



Larry W. Loen  -   Senior Java and AS/400 Performance Analyst
                          Dept HP4, Rochester MN

speaking, as always, on his own

+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---