[TriLUG] XML and DOM

[Mike M]

On Monday 10 March 2003 15:27, Joseph Tate wrote:
> Mike M wrote:
> >1) Configuration.  I've got a draconian mess that needs to be hidden from
> > the normal user.  I want to make a configurator that queries the user and
> > outputs an XML file.  The XML configuration file is then accessed by the
> > application during startup and operation.
>
> What's the use case?  Is the user going to use a web browser?  Some GTK+
> type app?  Something that runs on Windoze?  A handheld?  

I think command line to begin with and a web interface later.  I need to 
spend a minimum of time up front without making too many compromises that 
discourage subsequent embellishment.

> When we started
> working on our app more than two years ago, libxml hadn't been ported to
> Windows CE, so we couldn't use it there, but since then it has.  It
> would be my library of choice.  There are wrappers in just about every
> language you can think of, whether you use tcl or perl, C++ or PHP.  In
> the open source world that's the de facto XML library for both SAX and DOM.

I recall libxml being brought in when I loaded some DocBook stuff last week.
>
> >2) Interpretation.  I need to create an interpreter between a complex
> >protocol (where much of the complexity is unneeded) to a simple protocol.
> >The complex side is established and institutionalized.  The simple side is
> >being designed from scratch and is TCP/IP sockets-based.  Both sides
> >structure information formally.  I am thinking that the simple side
> > message format should be implemented in XML. The application receives a
> > simple side message and converts it to a complex side message, and
> > vice-versa.
>
> If you are designing both the simple protocol and the clients that
> listen to the protocol you might look into SOAP.
> Just choose your platform.  Check out Apache's Axis, PHP's Pear::SOAP,
> Perl's SOAP package from CPAN, or any other implementation you like.
>  You'd get that mostly for free with SOAP.  It usually runs over HTTP,
> though there are asynchronous implementations as well.  Then you can say
> your product is web services enabled.  If you care about that kind of
> thing.

I'll check it out.  I do have the ability to deliver both the client and the 
server.  Being a WSE app might not be a bad thing. 
>
> >Is XML a good technology for what I describe above?  More detail available
> >upon request.
>
> Sounds fair.  XML is nice and extensible.  The tricky thing is
> generating the WSDL the DTD or the SCHEMA to describe your document.
>  There are advantages to each, but as of yet I haven't found good "Free"
> tools to do what I've needed.  Of course sometimes researching that is
> more work sometimes than simply breaking out your favorite text editor
> for very simple designs.
>
Emphasis on the "very simple" in this case.  The ratio of message fields is 
simple=5:complex=80-100.

Thank you for your comments.  They were very helpful.
-- 
Mike M.