> As available technology is constantly evolving, it makes no sense to
> *rely* on a specific implementation, and thus a specific format.
> It's simple risk management. This is why people should be relying
> on a code interface to access data, not a specific format. By
> relying on a code interface, it simply doesn't matter if the
> implementation changes - in fact, it *promotes* evolution of the
> implementation - and healthy competition in that area.
> Thanks for your comments,
What if an alternative version of the DOM API were implemented so
that, instead of giving access to a tree built from an XML file, it
gave access to a lightweight database in which XML files had been
stored in some standardized format, probably in the form of a
This might not answer some of your criticisms about text not being
the appropriate representation for some types of data.
However, it would address some of the limitations we would run into
when trying to use XML files as databases. For example, it would
enable applications to update them.
For this to work, that lightweight database access support would
have to be freely available on all platforms, so that anyone could
build access (use the DOM database API) into their application.
And, we would need convenient ways to compile XML files into such a
lightweight database and to export the contents of an XML database
to an XML text file.
What do you think? Would this capability make XML more useful for
some of the purposes you have in mind?