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


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Verboseness - XML Syntax for XQuery 1.0 (XQueryX)

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?


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 

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.


                               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