RE: HTML to XML, vice versa

Brad Stone asked:

>But, if you want to use XML, where do you get
>the tag names from?  Are they
>hard coded into the decorator?

Yes, that would normally be the case.  Here's why.  I'm going to
assume that people reading this know nothing of XML.  If you
do, bear with me, because I'm going to connect it to O-O as
I explain it.

XML is subtly different from HTML.  With HTML, some world-wide
committee somewhere predefines all the tags.  HTML really is a poor
precedent
for thinking about XML.  XML is much more local and specific than that,
even
when local means "anyone manufacturing pencils."

XML is a really a way for _you_ or at least _you and your friends
in the same industry_ to define a specifc language just for your needs.
XML is really a "family of languages following a known set of rules."

So, when you read the XML books, there's all kinds of vague
looking examples like:

<employee>
   <name>Joe Smith</name>
   <number>7153433</number>
   <address1>133 Main Street</address1>
   . . .
</employee>

Since it is a book, they never get specific enough.  But, they do
give a flavor for what's really going on.  Real XML that we will deploy
will look about like that.

Probably the best analog for this audience would be a relational
data base.  This isn't perfect, but it is a place to start.

Basically, a good but not perfect start for understanding XML is
to pretend the tag names are the same as field names in a relational
data base.  This already is inexact, because "employee" is obviously
a collection of individual fields (it is perhaps a closer analog to a
record name in RPG), but the main idea still holds.

That means that, in general, you will be dealing with a specific
XML subset that is meaningful in the context of your business, especially
when the B2B definitions take off and various "marketplaces" develop,
each with their own XML definition.

Whether the XML ever makes it into a data base or not, whether the
XML tags are one-to-one with data base field names or not, the
basic idea holds -- XML tags are defined for roughly the same needs and
roughly the same reasons we define "records" "files" and "fields within
records."  XML tags can be more and less than these things, but they
arise for the same kinds of reasons.

Accordingly and critically, each tag (e.g. address1) will be more than
just a character string.  It will have its own meaning (here, a street
address).
That means a "decorator" function can and will want to record information
and concepts particular to "address1" -- this is classic O-O design.
You'll
probably have an "address1" object and its associated "address1 decorator"
object.  You might even have one that does both, but let's stick with
separate
objects.

The specifics of "what an address1 means" will reside in both the
decorator object and the more general address1 object.  They will want
and even need to hard code a lot of things that used to appear as
parameters on procedural language calls.  For instance, and address1
object will want to do whatever kind of validation makes sense for a
street address.  While there's a lot of variability here, not just any
old string will do.  I don't think "tilde" characters are normally allowed,
for instance, at least not in the USA.

This is one of the great benefits of O-O in fact.

Instead of coding:

    print("<address1 country=\""+country+"\">"+contents+"</address1>")

all over the place (in places that happen to need to "export" XML but
really would rather not know all about each XML tag and its output
quirks), you do something more like:

   print( new address1Decorator(address1_object).toString() );

which could even be:

   print( DecoratorFactory.generateXML(someXMLobject));

which sorts out which XML tag is presented, finds the right
decorator to create, extracts the information from
the associated "someXMLobject" and simply return a string with the
<address1>stuff</address1> or whatever the right stuff is.

This is similar to my generic tag example; if it was a tag like
employee, it would even cover doing the DecoratorFactory function
recursively to extract the strings for the various XML tags contained
in "employee" and returning one, big XML string that encoded the
whole wad.  And, best of all, the code that invoked it wouldn't know
or care whether it was "employee" or "address1" because all it
wants is to create the XML fragment corresponding to whatever the
heck it was someone passed in.

Exporting XML for some "real world" entity is, in fact, a great little
O-O problem.  It's a great teaching example.


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


+---
| 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
+---