OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Newbie looking for resources (want to create XML app for

[ Lists Home | Date Index | Thread Index ]

[oops, forgot to copy replies to the list.  Any and all feedback welcome!]


Thanks for the replies...

> One thing you should consider then is using XML as a data transport --
> you can think of it as a WAN version of ODBC. There are lots of tools
> for transferring data between XML documents and relational databases. In
> the case of Access, the simplest tool to use is probably ADO.

Yeah, I've started looking into that for the initial transfer of data out of
Access, but I probably won't need to put any back in, as I explain below...

> The result is that you get portability through XML, rather than storing
> your data in XML. For example, you could take your data from Access,
> serialize it as XML, and transfer it to SQL Server, Oracle, MySQL, etc.
> You then get the benefits of both portability and existing databases.

All valid, but overkill for my simple purpose.

> I'm not sure about spreadsheets, but Excel might be able to read/write
> XML. I also think I've heard that StarOffice on Linux uses XML as its
> native format.

I've checked into this.  StarOffice basically translates a given file into a
series of XML files, then zips them into a new (proprietary?) file.
Although it will open a standard XML file as plain text, it does not allow
you to work with it as a structured document, as far as I've been able to
tell.  That said, it *is* a pretty nice product.

> > To be clear, I have no plans to replace Excel and Access with custom XML
> > apps.
> That wasn't clear to me. In your original email, you said "add VBScript
> and DHTML to manipulate and query data (to replicate what I'm currently
> doing in MS Access". If what you are doing in Access is SQL queries,
> storing your data in XML and doing queries with VBScript and DHTML will
> guarantee a lot of work (you'll reinvent the wheel writing a query
> processor) and poor performance (XML documents are slow to access
> without indexes).

To clarify further: my current spreadsheet and database are both pretty darn
simple, and that's all they need to be for my purposes.  All I do is add,
modify and delete records, and view tabular lists (not even reports,
really).  For simple data modification and viewing lists, I *think* XML
should work pretty well in my case.  I agree: if I were doing "real" queries
with SQL, there wouldn't be much point in migrating.  As for performance,
I'm hoping that my generic plan will take care of that (more below).

> It's a great transfer and archive format. I'm not convinced it's a good
> format for working copies of data that fits well into a database or
> spreadsheet.

Since I use both my spreadsheet and database as nothing more than formatted
displays for reference, I think XML should do the job well.

> > The music collection started as a spreadsheet, which I planned to
migrate [...]

> Fair enough. I just thought I'd throw in my two cents. One of the most
> common XML/database questions I see is people wanting to throw away
> their databases and use XML instead. In the overwhelming majority of
> cases, this is a bad idea, but there are always exceptions.

I understand.  I think it will work in my case since I basically just need
some customized displays of (mostly) static data.

Here's my current pseudo-flowchart plan:

artists.xml contains artist names and notes, with tagged references to
individual [artistname].xml files

[artistname].xml contains <releases> by the artist, with associated <track>
lists and <notes> for each release.

The VBS/DHTML would have a main display that lists artist names from
artists.xml.  On choosing an artist, individual [artistname].xml files would
be loaded.  I would probably show only certain information by default, and
further information at the click of "More detail" buttons.

I would also have "Edit" buttons to modify/add/delete artists, releases, or
any other information.

The only real querying I plan to do is list:
all <artists>
all <releases> by an <artist>
all <releases> by all <artists> (if not too slow)
all <tracks> on a <release>
all <releases> purchased in last month or year
all <releases> total cost/value

All of that should be pretty straightforward with VBS/DHTML.  I'm hoping
that separating each artistname.xml file will help with speed of

Any more thoughts?



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS