> XML is a way to define, organize and express data in human readable text
> format. By definition it is extremely verbose, which puts it counter to
> the way of Palm, where all our data is scrunched up into the smallest
> space possible due to RAM size constraints.
It's important to note that XML as a language has absolutely nothing
at all to do with HTML or the web. XML is also not generally intended to be
read by humans, although, being 7-bit ascii text, it gains that as an added
benefit, in much the same way that MyAddressDB.c is human-readable. Look at
all of the non-HTML ways of using XML now, MathML, VSS-ML, and others.
XML is used to "describe" data. It is not meant to display data. It
is not meant to do anything else except "describe" how data is represented.
It does nothing more than this. Being such a powerful, extensible language,
you will most-likely never ever see version 1.1 of the XML specification.
You can do everything you want with it now, including evolve any tools into
and out of it you wish.
That being said, XML can also be used to "describe" data which is
meant for presentation on port 80 via http (ala web). You would use an XML
document plus a DTD and an XSLT transformation and probably a style sheet to
format that data, and then from the combination of those, output HTML. Some
browsers can make a best-attempt at representing XML "raw" in a browser, but
that's definately not it's intended output format.
For me, I am using XML in a test capacity to hold and "represent" my
Palm data on my desktop. I am beginning to mature the pilot-link toolchain
to handle the input and output of this format natively. Why do I want to do
this? Because now with a common way to "describe" the data and records on
the Palm (all the fields in each database on the '4 Magic Buttons'), all of
the tools which need access to that data don't need to deal with convoluted
pack()/unpack() routines to gain access to it (JPilot, Evolution,
gnome-pilot, KPilot, PilotManager, XPalm Desktop, OpenOffice, StarOffice,
and all of the other Palm-enabled GUI applications under linux, there are
dozens of others I didn't mention. Currently, all of them have their own
local data storage format. Nightmare!)
Simply passing these applications a DTD and my XML document which
"describes" that data, and they're done. They could then apply their own
XSLT transformation to it, and output a text file, an Access database, push
it into a MySQL database, or like I have here, sync their Palm with a CVS
server directly.
...or you could output HTML. HTML is the end format, not an
alternate step in-between any of the above processes.
I don't want to go into a full XML tutorial here, and this skipped
many points, but the general points were made. I just get miffed when people
try to compare XML to HTML. That's akin to saying that a blueprint is the
same thing as my Jeep Comanche sitting in my parking spot. One describes the
creation of the other (in the case of my Jeep, it's a 1:1 relationship, but
in XML, it's 1:<infinity> depending on which DTD and XSLT you choose to
apply). The blueprint does nothing, but apply some engineers and some tools,
and you can create a Jeep out of what it describes. Or you could create a
book which describes the processes. Or.. anything.
Remember, XML does NOTHING at all, except describe data. It's not an
"active" thing. It's a passive container of data structures.
> I don't see XML playing a major role on Palm devices any time soon when
> the typical device only has a few MB of RAM and a relatively slow
> processor. Sure, there will be some Palm applications using XML, but
> not nearly as many as you'll see using it on PC's and CE devices.
I completely disagree. XML allows the same data, and I mean the SAME
EXACT data to be used on a Palm, a PC, a laptop, a cell phone, a webserver,
my car computer, my handheld tablet, and my printer. It also allows me to
store that data in any system I choose, where I want, and with immediate
access to it, or any minute parts of it, from anywhere, at any time, using
any tools. When I ask for an address record, I know that the same EXACT
record is what will be returned on my cellphone, my desktop, my tablet, and
my handheld.
If you're speaking about using an actual XML parser ON the Palm, I
agree. That's not where the parser should go. The parser should go where the
data is manipulated, not where the data is displayed. Use the processing
power of the machine on your desktop to do the processing, not the end-user
display device. Don't burden the users with unnecessary bloat where it's not
needed. Besides, sync'ing a full-blown XML document including parsing
logic, DTD and XSLT to and from a Palm would be painful, when really all the
Palm wants is the data.
XML does this today. Used in a properly-architected system, of
course.
/d
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
