XML parser and writer

[Brandon McCombs]

Hey guys,

I'm writing a program to help people track various items and placing
them on a calendar. These items are mainly ones that reoccur (monthly
bills for example). Each item (or task) has various properties that are
set for it and I was thinking of storing all the data in an XML file.
I'd parse the file and have the data available throughout the execution
of the program. Updates to the file would occur when someone edits a
task to change its re-occurrence frequency, etc. Therefore I will need
to both easily parse and write new XML files. I don't have a DTD or
schema developed and I may later so any API I use will have to work w/o
that for now. Can anyone suggest a simple API for parsing/writing my own
made-up XML files? I've ruled out SAX since it only parses and was
thinking of using DOM but I don't know if that will work because I've
never did any programming with XML before.

thanks for any pointers

Brandon

 

[Sean]

Hey guys,

I'm writing a program to help people track various items and placing
them on a calendar. These items are mainly ones that reoccur (monthly
bills for example). Each item (or task) has various properties that are
set for it and I was thinking of storing all the data in an XML file.
I'd parse the file and have the data available throughout the execution
of the program. Updates to the file would occur when someone edits a
task to change its re-occurrence frequency, etc. Therefore I will need
to both easily parse and write new XML files. I don't have a DTD or
schema developed and I may later so any API I use will have to work w/o
that for now. Can anyone suggest a simple API for parsing/writing my own
made-up XML files? I've ruled out SAX since it only parses and was
thinking of using DOM but I don't know if that will work because I've
never did any programming with XML before.

thanks for any pointers

Brandon

I prefer DOM parsing. SAX may be simpler at times, but DOM seems more
organized and flexible to me. Not having a DTD or Schema may not be
important to you if you don't care about validating the XML files. You
can still pull elements and properties (and the content, of course) from
your XML with no problems.

Processing XML files in Java requires a good amount of knowledge about
XML and how it's parsed. You may want to head over to w3schools and
study XML thoroughly before starting.

 

[Lew]

I prefer DOM parsing. SAX may be simpler at times, but DOM seems more
organized and flexible to me.

That is not the characterization of the difference between them. Actually,
most people I've talked to about it find DOM simpler than SAX, but that's not
inherent in the libraries but in the way people understand them.

SAX is every bit as organized as DOM. I see no meaningful metric of
"flexibility" by which to compare them - it's like saying an tractor is more
"flexible" than a cow.

SAX and DOM serve different purposes.

Farmer: I can't afford a tractor. I'm fixing to buy a cow.
Tractor salesman: You're gonna look mighty silly plowing the fields riding a cow!
Farmer: I'll look a mite sillier trying to milk a tractor!

 

[Jeff Higgins]

Hey guys,

I'm writing a program to help people track various items and placing them
on a calendar. These items are mainly ones that reoccur (monthly bills for
example). Each item (or task) has various properties that are set for it
and I was thinking of storing all the data in an XML file. I'd parse the
file and have the data available throughout the execution of the program.
Updates to the file would occur when someone edits a task to change its
re-occurrence frequency, etc. Therefore I will need to both easily parse
and write new XML files. I don't have a DTD or schema developed and I may
later so any API I use will have to work w/o that for now. Can anyone
suggest a simple API for parsing/writing my own made-up XML files? I've
ruled out SAX since it only parses and was thinking of using DOM but I
don't know if that will work because I've never did any programming with
XML before.

thanks for any pointers

Maybe a Java-XML binding framework?
XStream, Castor, JAXB come to mind.

 

[Jeff Higgins]

Maybe a Java-XML binding framework?
XStream, Castor, JAXB come to mind.

OTOH, why not some database technology?

 

[Brandon McCombs]

OTOH, why not some database technology?

I thought about an internal (to the app) database however I wanted to
strike a balance between beginning and advanced user configurability and
the ease with which to carry the user settings from computer to
computer. In my mind, an advanced user can edit the XML file directly at
the risk of messing stuff up (that's where it would be nice to
eventually have a schema defined) instead of using a GUI interface I'll
eventually create for beginner users. Simply copying the XML file from
1 computer to another makes it easy for a user to use the application on
multiple computers if desired (although it would be up to them to keep
them sync'ed up).

Using a database made both of those things more difficult in my mind. An
advanced user would have no way of modifying an internal db and an
external db would just be overkill and make the installation of the app
overly complicated.

Any thoughts to the contrary? Maybe my knowledge is incorrect regarding
internal (embedded?) databases.

thanks
Brandon

 

[Brandon McCombs]

Maybe a Java-XML binding framework?
XStream, Castor, JAXB come to mind.

I mentioned this issue to a guy at work and he mentioned JAXB so I'll be
looking into that. I don't know exactly what Java-XML binding does so
I'll have to read up on it.

 

[Arne Vajhøj]

I mentioned this issue to a guy at work and he mentioned JAXB so I'll be
looking into that. I don't know exactly what Java-XML binding does so
I'll have to read up on it.

It maps between Java classes/objects and XML.

In short: you just tell it to write or read a Java
object as XML.

Arne

 

[Arne Vajhøj]

I'm writing a program to help people track various items and placing
them on a calendar. These items are mainly ones that reoccur (monthly
bills for example). Each item (or task) has various properties that are
set for it and I was thinking of storing all the data in an XML file.
I'd parse the file and have the data available throughout the execution
of the program. Updates to the file would occur when someone edits a
task to change its re-occurrence frequency, etc. Therefore I will need
to both easily parse and write new XML files. I don't have a DTD or
schema developed and I may later so any API I use will have to work w/o
that for now. Can anyone suggest a simple API for parsing/writing my own
made-up XML files? I've ruled out SAX since it only parses and was
thinking of using DOM but I don't know if that will work because I've
never did any programming with XML before.

Either database or one XML file per something. One huge XML file
will not work for updates.

If you go for XML then W3C DOM or an even higher level API would
be best.

Arne

 

[Bruintje Beer]

Hey guys,

I'm writing a program to help people track various items and placing them
on a calendar. These items are mainly ones that reoccur (monthly bills for
example). Each item (or task) has various properties that are set for it
and I was thinking of storing all the data in an XML file. I'd parse the
file and have the data available throughout the execution of the program.
Updates to the file would occur when someone edits a task to change its
re-occurrence frequency, etc. Therefore I will need to both easily parse
and write new XML files. I don't have a DTD or schema developed and I may
later so any API I use will have to work w/o that for now. Can anyone
suggest a simple API for parsing/writing my own made-up XML files? I've
ruled out SAX since it only parses and was thinking of using DOM but I
don't know if that will work because I've never did any programming with
XML before.

thanks for any pointers

Brandon

Have a look at Castor project

John

 

[Sean]

That is not the characterization of the difference between them.
Actually, most people I've talked to about it find DOM simpler than SAX,
but that's not inherent in the libraries but in the way people
understand them.

SAX is every bit as organized as DOM. I see no meaningful metric of
"flexibility" by which to compare them - it's like saying an tractor is
more "flexible" than a cow.

SAX and DOM serve different purposes.

Farmer: I can't afford a tractor. I'm fixing to buy a cow. Tractor
salesman: You're gonna look mighty silly plowing the fields riding a
cow! Farmer: I'll look a mite sillier trying to milk a tractor!

I should probably have left that out, since I have extremely little
experience processing XML with Java. I thought I knew what I was talking
about, but sadly I didn't.

 

[Jeff Higgins]

I thought about an internal (to the app) database however I wanted to
strike a balance between beginning and advanced user configurability and
the ease with which to carry the user settings from computer to computer.
In my mind, an advanced user can edit the XML file directly at the risk of
messing stuff up (that's where it would be nice to eventually have a
schema defined) instead of using a GUI interface I'll eventually create
for beginner users. Simply copying the XML file from 1 computer to
another makes it easy for a user to use the application on multiple
computers if desired (although it would be up to them to keep them sync'ed
up).

Using a database made both of those things more difficult in my mind. An
advanced user would have no way of modifying an internal db and an
external db would just be overkill and make the installation of the app
overly complicated.

Any thoughts to the contrary? Maybe my knowledge is incorrect regarding
internal (embedded?) databases.

Well, first, thanks for the invitation to exercise my contrarian tendency.

And second, my extensive knowledge of and real development experience with
the above subjects are hereby disclaimed.

I can say though that I have tried unsuccessfully more than once to soften
my hard head against the difficulty of using the Document Object Model
as a relational database. I think it could make sense to allow your user
to import and export his Calendar in XML format for the purpose of
transport.
But as a data model for something even as simple as a single user Calendar/
Tasklist the DOM would quickly become unwieldy especially if you have any
intention of using any part of the relations in the relational database.
You may also consider your Calendar over time, and over multiple users,
and over feature creep and over data types. Querying the DOM for all high
priority alerts after noon in the second week of January.

Having that said; If you view tour Calendar as a document the the DOM is
certainly the way to go.

JH

 

[Lew]

I have ... little
experience processing XML with Java.

My first use of Java for XML was using SAX. SAX is fast - you can parse an
entire document in a single pass and do things with what you find. If what
you do is build an in-memory structure, you can customize the structure to
your heart's content, modifying and altering elements as you retrieve them.
What you end up with internally has little conceptually or structurally to do
with XML any more; you've extracted all the juice from the XML and thrown away
the tags.

SAX isn't all that easy at first in that it is built on callbacks. People who
use Bean and Swing Listeners will grok the event-driven style pretty quickly.

DOM is simpler in way - its structure is an exact mirror of the XML
document's, treating containment by a tag as descent into a tree. If you want
a different in-memory structure, you need to build it separately, making the
DOM tree and your custom structure two separate bodies in cyberspace. This
requires more memory than SAX parsing. OTOH, your DOM tree stays in memory
for repeated mamipulation or query. Complicated operations or transformations
that can't happen in a single pass are straightforward in DOM idioms.

Since DOM maintains its structural parallelism with the XML document, it isn't
hard to write a DOM out to an XML format.

 

[David Segall]

I thought about an internal (to the app) database however I wanted to
strike a balance between beginning and advanced user configurability and
the ease with which to carry the user settings from computer to
computer. In my mind, an advanced user can edit the XML file directly at
the risk of messing stuff up (that's where it would be nice to
eventually have a schema defined) instead of using a GUI interface I'll
eventually create for beginner users. Simply copying the XML file from
1 computer to another makes it easy for a user to use the application on
multiple computers if desired (although it would be up to them to keep
them sync'ed up).

Using a database made both of those things more difficult in my mind. An
advanced user would have no way of modifying an internal db and an
external db would just be overkill and make the installation of the app
overly complicated.

Any thoughts to the contrary? Maybe my knowledge is incorrect regarding
internal (embedded?) databases.

Most of the open source embedded databases including the two that can
have their tables in memory (HSQLDB and H2) can be embedded and,
simultaneously, client-server. That means that a user can change them
using, say, OpenOffice Base. You may also find OpenOffice Base a
useful RAD tool for building your GUI interface. The problem of
synchronizing the configuration files may be eased by using database
replication which is well understood. I have list of embedded
databases at http://database.profectus.com.au/#java. There are some
tools and add-ons for synchronising these databases but I have not
used them.

 

[Brandon McCombs]

Well, first, thanks for the invitation to exercise my contrarian tendency.

And second, my extensive knowledge of and real development experience with
the above subjects are hereby disclaimed.

I can say though that I have tried unsuccessfully more than once to soften
my hard head against the difficulty of using the Document Object Model
as a relational database. I think it could make sense to allow your user
to import and export his Calendar in XML format for the purpose of
transport.
But as a data model for something even as simple as a single user Calendar/
Tasklist the DOM would quickly become unwieldy especially if you have any
intention of using any part of the relations in the relational database.

I didn't plan on using a database at all whether for storing user data
or user/application settings. If the DOM becomes unwieldly, and SAX
can't marshal new XML documents then what should I use if I want to
stick with XML? I think I want to stick with XML because I thought it
was the modern technology to use for not only storing data but
configuration settings.

In the past I've used the Java Preferences API and it was great for
easily retrieving, manipulating data, and then storing changes but the
changes weren't portable nor editable without my custom GUI which
provided both edit and import/export features. The Preferences API is
just for settings and not for data so I figured I'd have to look to
something else this time.

The XML file I plan to use is going to store not only the properties of
a task (name, description, frequency, etc.) but also all the dates on
which the task will occur (based on frequency) which is what I would
consider the data in this situation. When the application starts up, and
just before the current month is displayed, I build a data structure
that contains all the dates for all the tasks on a month by month basis
(the biggest timespan displayed by my GUI so far) so every time a month
is displayed in the calendar all the tasks and all their occurrences are
displayed. I also plan to have a list-like view of a single task, all
its occurrences, and the status for which occurrences of that task have
been completed.

A user may modify the frequency of a task, complete a single or multiple
occurrences of a task, or create/delete a task and I was hoping an API
was available for me to easily handle data elements, that were sourced
from an XML file, to accomplish those user actions.

That's what I have in my head so far for designing this. Note that this
is just a for-fun project I thought I'd try for my own benefit so at
this point there is no need for it to be enterprise-ready (i.e.
multi-user, etc.).

At this point the calendar displays better than I imagined and I'm
trying to wrestle around how to compute, store and display multiple
occurrences of a single task, hence this thread.

You may also consider your Calendar over time, and over multiple users,
and over feature creep and over data types. Querying the DOM for all high
priority alerts after noon in the second week of January.

If this was a professional project I would but I'm not worried about
that level of sophistication for something like this although your
example of a query probably isn't out of the question but it wouldn't
return any more than a handful of results for a user like myself or a
family member who might benefit from my program.

 

[Roedy Green]

. I don't have a DTD or
schema developed and I may later so any API I use will have to work w/o
that for no

Have a look at the XSD schema for JNLP. I think you will get the idea
pretty quickly how it works.

http://mindprod.com/jgloss/jnlp.html

Asking end users to compose XML might get you in trouble for violating
the Geneva conventions. You probably want to do something like I am
in my new VerCheck Utility where you have a JTable of options you fill
in, and persist using the Java persistence mechanism. No XML
anywhere.

http://mindprod.com/jgloss/jtable.html
http://mindprod.com/jgloss/persistence.html

I have put it on hold. I am busy preparing all my C/C++ utilities to
run under windows instead of DOS, to use POSIX, and to have icons, and
PADS. Check back in a week or two and you can steal the code.

I have VerCheck pretty well working, but no edits yet, and the
threading is still flaky.

 

[Jeff Higgins]

Brandon McCombs wrote
Please don't get all excited about what I have to say. I'm a hobbyist
programmer and as such don't have the depth of knowledge or experience
that some others here have.

I didn't plan on using a database at all whether for storing user data or
user/application settings. If the DOM becomes unwieldly, and SAX can't
marshal new XML documents then what should I use if I want to stick with
XML? I think I want to stick with XML because I thought it was the modern
technology to use for not only storing data but configuration settings.

Spend some time and figure out your use cases and data model and then pick
an appropriate technology with which to implement it. Starting out
designing
a GUI and then fitting a data model to that is counter-productive.

In the past I've used the Java Preferences API and it was great for easily
retrieving, manipulating data, and then storing changes but the changes
weren't portable nor editable without my custom GUI which provided both
edit and import/export features. The Preferences API is just for settings
and not for data so I figured I'd have to look to something else this
time.

Don't know much about the Preferences API.

The XML file I plan to use is going to store not only the properties of a
task (name, description, frequency, etc.) but also all the dates on which
the task will occur (based on frequency) which is what I would consider
the data in this situation. When the application starts up, and just
before the current month is displayed, I build a data structure that
contains all the dates for all the tasks on a month by month basis (the
biggest timespan displayed by my GUI so far) so every time a month is
displayed in the calendar all the tasks and all their occurrences are
displayed. I also plan to have a list-like view of a single task, all its
occurrences, and the status for which occurrences of that task have been
completed.

Good. Data model and use case planning.

Spend a bunch of time researching and experimenting with
Java-XML technologies. Including how (!) to use xml as a database.
This could become a career-long endeavor.

A user may modify the frequency of a task, complete a single or multiple
occurrences of a task, or create/delete a task and I was hoping an API was
available for me to easily handle data elements, that were sourced from an
XML file, to accomplish those user actions.

Good. Building use cases.

Java-XML binding frameworks.

That's what I have in my head so far for designing this. Note that this is
just a for-fun project I thought I'd try for my own benefit so at this
point there is no need for it to be enterprise-ready (i.e. multi-user,
etc.).

Don't know about enterprise ready.
Multi-user is probably not synonymous with enterprise-ready.

At this point the calendar displays better than I imagined and I'm trying
to wrestle around how to compute, store and display multiple occurrences
of a single task, hence this thread.

Good deal. I saw your earlier thread and it sparked some interest in
a Calendar wiget.
See remark above.

If this was a professional project I would but I'm not worried about that
level of sophistication for something like this although your example of a
query probably isn't out of the question but it wouldn't return any more
than a handful of results for a user like myself or a family member who
might benefit from my program.

I didn't explicate very well there. I guess what I was getting at was
that database technology is good for implementating databases and
XML technology is good for implementing Extensible Markup Language
functionality.

 

[Jeff Higgins]

Hey guys,

I'm writing a program to help people track various items and placing them
on a calendar.> thanks for any pointers

<http://www.mozilla.org/projects/calendar/sunbird/>
<http://icalshare.com/>
<http://www.ietf.org/rfc/rfc2445.txt>

 

[Jeff Higgins]

Jeff Higgins wrote

<http://www.mozilla.org/projects/calendar/sunbird/>
<http://icalshare.com/>
<http://www.ietf.org/rfc/rfc2445.txt>

<http://ical4j.sourceforge.net/>