[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Verboseness - XML Syntax for XQuery 1.0 (XQueryX)
- From: Alaric Snell <alaric@alaric-snell.com>
- To: The Deviants <xml-dev@lists.xml.org>
- Date: Sat, 16 Jun 2001 16:36:37 +0100 (BST)
Quoting Jonathan Robie <Jonathan.Robie@SoftwareAG-USA.com>:
> How important is this, and why is it important? Why would humans prefer
> to
> write queries in an XML syntax?
*mirth*
One of the worst things about the XML community is it's divideness. There is no
one clear answer to anything.
I've debated with people who love XML for data storage ("I can just XSLT it
into web pages statically!") but who think that it's stupid to use for
communication between purely software agents (XML from database into XSLT, or
SOAP) - they see it as a replacement for CSV, or maybe configuration files,
where one party is always a human. I have a fair amount of sympathy with these
people, our only difference is that I say "sometimes XML will be useful", they
say "always use XML! Nothing is better!".
I've debated with people who think that XML is a truely universal data format,
fine for describing filesystems, archive files, bitmapped images, the lot;
storage, bandwidth, and CPU time is cheap; these people never seem to have
waited for a data-intensive process to complete.
I've heard people claim that human readability (with no special tools) of all
data is vital, saying that we should pay a runtime penalty to cater for the
case of developers with no development tools. Some of these allow gzip as a
special encoding tool. None of them allow structured data editors (such as can
be had for ASN.1 BER-encoded data), saying that requiring such a tool will shut
out developers (well, so will the requirement for a much more complex C
compiler...)
Now we have somebody who is saying that human readability of these XQuerys
isn't a great issue, since they will mainly be processed by automatic tools.
Presumably human readability will only rarely come in when debugging something
at a very low level. I agree with this person, but I doubt many others will
around here.
I've worked without problem with Java serialisation used as a universal data
format. Whether used in database tables, in files, or over with wire with RMI,
I've never been in a situation during developing those systems where I've been
without a Java development kit, strangely, so needing a JDK to decode the
serialised objects and then get debug dumps of them has never actually been a
problem. The data could be rendered to readable form when I needed it, but the
day to day running of the system was not crippled with it.
Amusingly, as an experiment, we tried running the RPCs over HTTP, and the
system ground to a halt - an HTTP transaction took some tenth of a second, and
at the rate our system did work, that wouldn't do.
Java serialisation is flawed in that there are no non-java interfaces to it, I
agree, but the same rules can apply to IIOP, which is language independent.
There are lots of conflicting ideas and ideals here. I see this as dangerous
evidence of an effort without clear goals.
ABS
--
Alaric B. Snell
http://www.alaric-snell.com/ http://RFC.net/ http://www.warhead.org.uk/
Any sufficiently advanced technology can be emulated in software